ROX-11407: Support for Configurable Resource Limits for Central & Scanner

[mtesseract]

Description

• Extends the API for modelling resource settings.
• Introduces new admin endpoint for creating centrals with non-default resource settings.

There are plenty of generated files, which should, of course, be filtered out while reviewing.
Also, my editor has (unfortunately) streamlined the used quotation marks ("..." vs '...') in the API YAMLs, hence the diff to these files is unnecessary large.

Implementing the Update call for modifying resource limits will be done in a separate PR.

Test has been added.

Checklist (Definition of Done)

• Unit and integration tests added
• Documentation added if necessary
• CI and all relevant tests are passing

Test manual

TODO: Add manual testing efforts

# To run tests locally run:
make db/teardown db/setup db/migrate
make ocm/setup OCM_OFFLINE_TOKEN=<ocm-offline-token> OCM_ENV=development
make verify lint binary test test/integration

[mtesseract]

/retest

[kovayur]

I'm wondering if we need a pre-commit hook for yaml formatting

[mtesseract]

great idea

[kovayur]

LGTM, Good job @mtesseract

[mtesseract]

@kovayur, I had to rework the PR due to some Issues I have found. Let me explain.

• I did the following change:

-	Central     api.JSON `json:"central"` // Schema is defined by #/components/schemas/CentralSpec from the public API.
-	Scanner     api.JSON `json:"scanner"` // Schema is defined by #/components/schemas/ScannerSpec from the public API.
+	Central     api.JSON `json:"central"` // Schema is defined by dbapi.CentralSpec
+	Scanner     api.JSON `json:"scanner"` // Schema is defined by dbapi.ScannerSpec

which means that the internal representation of the central and scanner spec is defined by dbapi.CentralSpec and dbapi.ScannerSpecinstead of the OpenAPI generated models. I find this more logical (API models only for conversion at service boundaries) and also more reliable, because the models indbapi` are more strongly typed.

• I have streamlined the conversion functions in resourceutil.go and the validation functions in internal/dinosaur/pkg/handlers/dinosaur.go(there was also a bug in there).

• internal/dinosaur/pkg/presenters/dinosaur.go: Only attempt to unmarshal central and scanner in case they are non-empty. Same in internal/dinosaur/pkg/presenters/managedcentral.go.

• Fix a rebase error in internal/dinosaur/pkg/presenters/managedcentral.go.

• Fix a bug in route_loader.go which caused the wrong dinosaur handler to react to admin calls.

• Then finally: The internal refactoring of the types triggered a rather mysterious issue in internal/dinosaur/pkg/config/dataplane_cluster_config.go: due to a transitive (non-obvious) dependency on the k8s controller-runtime package we were hit by flag redefined: kubeconfig: allow double vendoring this library but still register flags on behalf of users kubernetes-sigs/controller-runtime#878. This caused fleet-manager to panic during startup. Until this is fixed in upstream I have added an ugly workaround, which is still the best I was able to come up with in the above file. It checks if the flag has already been defined and if so it modifies it to be in the shape that our application code expects. This seems to work nicely.

[kovayur]

Thanks for the explanation @mtesseract

I find this more logical (API models only for conversion at service boundaries)
Yes, this is more coherent, I agree

[mtesseract]

/retest

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kovayur, mtesseract

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [kovayur,mtesseract]

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