CLOUDP-356692: Support for exporting Atlas resources using auto-generated CRDs

[helderjs]

Proposed changes

This PR introduces support for exporting Atlas resources using auto-generated CRDs.

Important notes

1. Since the generated CRDs are not yet publicly released, we cannot fetch them from the AKO GitHub releases like we do for the existing CRDs. Instead, we've introduced an Embedded CRD Provider that bundles the CRD definitions directly into the binary using Go's embed package.
2. The resource exporters (GroupExporter, ClusterExporter, FlexClusterExporter, DatabaseUserExporter) reference types from the crapi testdata samples package. This is a temporary path because the generated CRD types are still internal to AKO and not yet published as a public API. Once the types are promoted to a public package, these imports will need to be updated.
3. The go.mod currently points to the AKO main branch. This is necessary because the crapi translator and generated types are only available in unreleased commits. Once AKO cuts a new release containing these changes, we should update to point to the stable release version.

Jira ticket: CLOUDP-356692

Checklist

• I have signed the MongoDB CLA
• I have added tests that prove my fix is effective or that my feature works
• I have added any necessary documentation in the document requirements section listed in CONTRIBUTING.md (if appropriate)
• I have addressed the @mongodb/docs-cloud-team comments (if appropriate)
• I have run make fmt and formatted my code

[josvazg]

q: Is this gofmt compliant? just curious

[helderjs]

It passed CI

[josvazg]

q: interesting! this is a new way of parsing using k8syaml right?

[helderjs]

No, it's nothing new. It came as same approach used in by other kube projects.
see https://github.com/kubernetes-sigs/controller-runtime/blob/679fb347b532c2278ee0e30469e322c96b75c091/pkg/envtest/crd.go#L424

[josvazg]

q: is this properly disabled for now?

[helderjs]

q: is this properly disabled for now?

No, I raised the question about put PR on hold vs feature flag.

[josvazg]

q: is this properly disabled for now?

No, I raised the question about put PR on hold vs feature flag.

IMO we should make this an experimental feature only enabled with a compile time flag. Similar to the experimental support already have in the AKO repo. If you agree I could setup that up in a separate PR and let you rebase on top later.
WDYT?

We will basically need to compile with a flag to get the experimental features and this would we one of them. we could try the UX manually or run e2e tests that leverage it.