Updated regions and VM SKUs available in Helper UI, and changed default SKU selections

[pjlewisuk]

PR Summary

• Updated list of locations to include all current regions
• Updated Kubernetes version to current default (1.29.7)
• Updated skuFamilies to include more recent VM gens and remove older gens
• Updated default SKU choices:
  • Default system node is now Standard_D4ds_v5
  • Default user node selected in GUI is also Standard_D4ds_v5
  • Cost optimised clusters use the latest gen burstable Standard_B4s_v2
  • High performance clusters use the Standard_D8ds_v5
• All workflows updated to use current gen SKUs
• Changed system and user node pool names to align more closely with portal defaults
• Updated logic to check whether each VM SKU has enough temp storage/cache to use ephemeral storage instead of managed storage for OS
• Changed default OS disk size to 128 GB (for both Windows and Linux) to match portal behaviour

PR Checklist

• [x] PR has a meaningful title
• [x] Summarized changes
• [x] This PR is ready to merge and is not Work in Progress
• [ ] Link to a filed issue
• [x] Screenshot of UI changes (if PR includes UI changes)

List of regions:

List of VM SKUs:

[pjlewisuk]

Over to you @samaea to review before merging :)

LMK if you want a quick call to run through the changes

[pjlewisuk]

I think at least part of the problem with this change is that with the 2024-01-01 and 2024-01-02-preview versions of the managedClusters API, there was a change of behaviour with unknown fields. From https://github.com/Azure/AKS/issues/4060:

All current AKS API versions silently ignore unknown fields. An unknown field is a field that is not part of the AKS API. Starting in AKS API version 2024-01-01 and 2024-01-02-preview this behavior is changing. Unknown fields in a request will result in the request being rejected with an error stating that we don't understand the unknown field. This change only impacts new API versions and will not impact you unless you update to use an API version 2024-01-01 or later. Existing API calls (via ARM templates or otherwise) will continue to function as-is.

I pushed a change to update the managedClusters API to use version 2024-01-01 back in April (PR-691), which could have impacted this, as the main error being reported during failed builds was that the natGatewayProfile parameter was not understood, or might have been in the wrong place in the file. Looking at history it looks like builds were already failing, so not sure if this change was the root cause or not.

I have also reverted the API version to 2023-11-01 (which on it's own didn't help) and have another PR lined up (PR-707) to update a number of API versions across the project.