Make azure and async spec type default values consistent with Azure Go SDK types

[Jont828]

/kind bug

The azure.AgentPoolSpec type (found in azure/types.go](https://github.com/kubernetes-sigs/cluster-api-provider-azure/blob/main/azure/types.go)) has fields such as AgentPoolSpec.AvailabilityZones which is a []string and AgentPoolSpec.VnetSubnetID which is a string. These types are used to initialize the Go SDK type containerservice.AgentPool which has corresponding pointer types such as AgentPool.AvailabilityZones which is a *[]string and AgentPool.VnetSubnetID which is a *string with code like this.

containerservice.AgentPool{
    AvailabilityZones: &spec.AvailabilityZones,
    ...
    VnetSubnetID:      &spec.VnetSubnetID,
}

As a result, when spec.AvailabilityZones and spec.VnetSubnetID are uninitialized with values [] and "", AgentPool.AvailabilityZones is set to &nil instead of nil and AgentPool.VnetSubnetID is set to &"" instead of nil. This results in a bug where the Azure Go SDK fields become initialized with pointers to default values. If the spec field is guaranteed to be set, this is not noticeable, but if not it will cause unit tests for the spec to fail.

[Jont828]

@CecileRobertMichon

[Jont828]

Another consideration is that sometimes we might want to pass a pointer to an int type. For example, containerservice.AgentPool.OSDiskSizeGB has the following description:

field OsDiskSizeGB *int32
OsDiskSizeGB - OS Disk Size in GB to be used to specify the disk size for every machine in this master/agent pool. If you specify 0, it will apply the default osDisk size according to the vmSize specified.

In this case we might not want to have it be nil if OS disk size is not in the spec.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[nawazkh]

/remove-lifecycle rotten

[dtzar]

IMO we should prioritize the migration to a supported SDK track first and fix this issue as we go along (if it's still appropriate).

[willie-yao]

/lifecycle frozen

We are prioritizing migration to ASO and will re-evaluate this depending on if it's still needed. More details at #3113

[dtzar]

Do you think this is still needed @Jont828 @nojnhuh @mboersma?

[nojnhuh]

I think the kinds of bugs this attempts to address are much less of a concern now with ASO. Overall I'm +1 to closing this and re-opening if we do encounter any more bugs that this would have saved. Or at least recording that this is very low priority.

[Jont828]

I'll defer to @nojnhuh on this since most of these spec types were replaced with the ASO types. Closing it out for now, and if we need to reopen, we could probably just make a new issue specific to ASO.

/close

[k8s-ci-robot]

@Jont828: Closing this issue.

In response to this:

I'll defer to @nojnhuh on this since most of these spec types were replaced with the ASO types. Closing it out for now, and if we need to reopen, we could probably just make a new issue specific to ASO.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.