[CRD] versioning support in StarrocksCluster

[mingmxu]

Describe the current behavior

Currently, CRD: StarrocksCluster has a fixed version apiVersion: starrocks.com/v1, without proper versioning and capability guarantee, the risk to upgrade CRD is unknown.

Describe the enhancement

Support versioning in CRD: StarrocksCluster, and add capability verification during CRD upgrade.

Additional context

Add any other context or screenshots about the enhancement here.

cc @dengliu @yandongxiao

[yandongxiao]

‌‌‌If we are just marking the version information of CRD, can we add the corresponding version information to the annotation or label of CRD?

[mingmxu]

It's good to stick using one version in CRD, if we're able to keep backward/forward compatible crossing the released CRDs:

• the old CRs can be parsed by the new operator, this eliminates the migration effort when upgrading operator/crd;
• the new CRs can be parsed by the old operator, this ensures it's safe to rollback operator upgrade;

Technically we can use webhook to rewrite CRs when compatibility is not guaranteed. I don't suggest to move that far until necessary, adding logic in operator to handle unset behaviors is much simpler.

---

Some more information in https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/