Remove multi_az documentation for aro_hcp

[mahesh-palkar]

For ARO-HCP, the multi_az flag is read-only and cannot be configured by the user. Internally, the field is unused, and as a non-pointer boolean, it defaults to false.
The reason is that once the value is mapped into the internal struct as a non-pointer, we can no longer distinguish whether it was explicitly set by the user or intended to be derived later via Azure APIs. Using a pointer would preserve this distinction but it will cause a broader impact on the codebase. Hence, using a pointer was avoided.

Ticket: https://issues.redhat.com/browse/ARO-17289
MR : https://gitlab.cee.redhat.com/service/uhc-clusters-service/-/merge_requests/9973

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mahesh-palkar
Once this PR has been reviewed and has the lgtm label, please assign vkareh for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @mahesh-palkar. Thanks for your PR.

I'm waiting for a openshift-online member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

[miguelsorianod]

@vkareh @etabak please take a look at this one and the design decision

[miguelsorianod]

@vkareh @etabak do you see the approach mentioned here ok?

Initially we wanted to still leverage the multi_az attribute in aro-hcp and make it readonly, reflecting its state, but we cannot determine its value at api create request/response flow synchronous time. It happens a bit later asynchronously.

At the same time, we cannot "unset" the value because at api layer because internally in the model it is a boolean, which does not allow to differentiate between false and unset. An option was changing the internal model from a boolean to a boolean pointer but that had broad implications on the existing codebase. Because of that, the decision has been to just not set any value for that attribute in aro-hcp (this MR formalizes that). This is, it is unused (null) always.

Another reason is because although a region in Azure might not have AZs/multiple AZs support, we don't know if that could not necessarily be the case over time, so it could be technically inaccurate information at some point, which added another argument to not set it.

[vkareh]

@miguelsorianod: by "approach", are you referring to the attribute documentation? That's the only change I see in this PR, and the API will be hidden by the RP anyway. Why not make it an internal validation in CS to ensure the RP cannot accidentally set/use the value?