[AKS] Honor addon names defined in Azure CLI

[kaiqzhan]

Description

AKS server treats addon names and addon config keys as case insensitive, and store them in DB as it is in input. For example, we have both logAnalyticsWorkspaceResourceID and loganalyticsworkspaceresourceid in our DB and both are valid. However, in the public document we're only giving examples of logAnalyticsWorkspaceResourceID.
This change makes Azure CLI always convert the keys to the name defined in Azure CLI. (The name defined in Azure CLI is the same as public document), so that customer get the right name back.

Testing Guide

1. Create a AKS cluster.
2. Run az aks enable-addons -a kube-dashboard -g testrg -n testcluster
3. The name of kube-dashboard addon name should be change from "KubeDashboard" to "kubeDashboard"

History Notes

---

This checklist is used to make sure that common guidelines for a pull request are followed.

• The PR title and description has followed the guideline in Submitting Pull Requests.

• I adhere to the Command Guidelines.

[kaiqzhan]

@robbiezhang

[yungezz]

could you pls add test to cover this?

[yungezz]

for != part, better to lower() before compare

[kaiqzhan]

Here my intention is to change the keys back to 'logAnalyticsWorkspaceResourceID'. The intention of key != 'logAnalyticsWorkspaceResourceID' is to skip if the key is already be 'logAnalyticsWorkspaceResourceID'.
For example, if the key is 'loganalyticsworkspaceresourceid' or 'LogAnalyticsWorkspaceResourceID', the value will be pop out and write back with key 'logAnalyticsWorkspaceResourceID'. But if the key is already 'logAnalyticsWorkspaceResourceID', it skips and nothing changed.

[fengzhou-msft]

can you assign 'logAnalyticsWorkspaceResourceID' to a variable and use the variable instead of using the hard-coded string in multiple places?

[kaiqzhan]

@fengzhou-msft We're already doing that pattern in azure-cli-extension. I'll change that in another pr.

[yungezz]

hi @kaiqizhang would you pls address comments? today is Code complete date, would you like to catch this release?

[kaiqzhan]

hi @kaiqizhang would you pls address comments? today is Code complete date, would you like to catch this release?

Oh, sorry for late. Will do it soon.

[yungezz]

hi @kaiqizhang just want to double confirm, this change will not cause existing users' breaking change right? little concern because it changed existing output

[kaiqzhan]

hi @kaiqizhang just want to double confirm, this change will not cause existing users' breaking change right? little concern because it changed existing output

It's a long story. 2 months ago, we did a breaking change on the server side. All the keys are converted to lower cases. Based on the IcM at that time and discussion in the team, we reverted the change. Some customer cares about the case because they're using json query in their script. With this change in Azure CLI, customers can change the case back if it's necessary for them. (customer can still use different case in Terraform, Postman, etc.)
Back to this question, it's possible that customer see different addon key if disable, re-enable a specific addon. But it aligns to our public document. I suggest we can mention this change in the change log.