Convert all singleton lists in the MR APIs to embedded objects

[ulucinar]

Description of your changes

Depends on: crossplane/upjet#387, crossplane/upjet#400, crossplane/upjet#402, crossplane/upjet#411

Terraform configuration blocks, even if they have a MaxItems constraint of 1, are (almost) always generated as lists. We
now generate the lists with a MaxItems constraint of 1 as embedded objects in our MR APIs.

This also helps when updating or patching via SSA the (previously list) objects. The merging strategy implemented by SSA requires configuration for associative lists and converting the singleton lists into embedded objects removes the configuration need.

The provider generates the converted embedded objects in the new v1beta2 version if the current API version is v1beta1 and in the v1beta3 version if the current version is v1beta2 and registers upjet's identity converter and the singleton list converters to be invoked, in chain, by the CRD API conversion webhooks. This implies that the current versions stay intact, and old clients not aware of the new APIs should continue functioning as before (backwards-compatibility). Any clients willing to use the embedded objects-based APIs should be updated to use the new (v1beta2 or v1beta3 as appropriate) versions of the CRD APIs.

If a resource contains no singleton lists in its API, then no new version for it is generated.

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable to ensure this PR is ready for review.
• Added backport release-x.y labels to auto-backport this PR if necessary.
• New versions for the converted CRD APIs
• Replace config.Resource.References[*].Type with config.Resource.References[*].TerraformName: Addressed in Use config.Reference.TerraformName instead of config.Reference.Type #1310
• API Conversion functions (invoked by the Conversion webhooks) to convert between the new & old API versions
• Switch controller watch target API versions to the current API versions
• Fix the configurations to address the inconsistency between the JSON & Go resource schemas regarding the MaxItems = 1 constraint: Implemented via traverser.maxItemsSync in Add config.Resource.RemoveSingletonListConversion crossplane/upjet#411
• Adjust the manually authored example manifests: Implemented in Add example manifests for the converted singleton list API versions #1334

How has this code been tested

Validated in #1334 via uptest runs.

[ulucinar]

/test-examples="examples/opensearchserverless/v1beta1/securityconfig.yaml"

[mbbush]

I wonder if it might make for a more consistent user experience if we set all of the updated versions to v1beta3, skipping v1beta2 for the resources that didn't have a breaking schema change in terraform provider 5.x.

What do you think?

[ulucinar]

I wonder if it might make for a more consistent user experience if we set all of the updated versions to v1beta3, skipping v1beta2 for the resources that didn't have a breaking schema change in terraform provider 5.x.

What do you think?

I'd prefer Kubernetes API conventions here. I feel like skipping versions would be another source of confusion for the users. Even if we attempt to synchronize versions with this PR, we will still need to bump individual versions for the API changes specific to individual resources. which will again unsync their versions.

[turkenf]

Thank you @ulucinar, LGTM.

[ulucinar]

We are adding the missing example manifest (which is also the reason the check-examples job is failing for this PR) in #1334...