initProvider support in upjet

[lsviben]

As described in granular management policies design, we are adding a new field spec.initProvider which will complement spec.forProvider during the external Resource Create. This will allow users to specify some fields that they would like or need(required fields) to set for the resource creation, but that they dont want Crossplane to control and later keep updated.

This behaviour also complements the granular managementPolicies, especially those which are skipping Late Initialziation.

Example usage for EKS NodeGroup:

  initProvider:
    scalingConfig:
      - desiredSize: 1
  forProvider:
    region: us-east-1
    scalingConfig:
      maxSize: 5
      minSize: 1

[turkenh]

I can think of two possible options here:

A. Copy everything under spec.forProvider to spec.initProvider as optional fields.
B. Enable an option to configure which fields should go under spec.initProvider to move parameters there on a case-by-case basis.

We identified that we would need to move the tagging in initializer from spec.forProvider to spec.initProvider to allow custom tags to be introduced and thought option A would be better since it will be needed for all resources.

However, I am still wondering if option B would be safer at least to start with and we can still use the configuration option to move tags to spec.initProvider for all resources? I am hesitant to start with option A, mostly because it will grow the schema of all resources significantly (FWIW, we already did once recently by moving everything from spec.forProvider to status.atProvider) and wouldn't have some real use cases.

@ulucinar @lsviben what do you think?

[lsviben]

I initially started to work on A. mostly because its simpler both in implementation, solves the tagging issue for all, and no later maintenance (requesting more resources to have this, other fields etc), but I get also that starting slow with an alpha feature makes sense.

Ill need to check and understand a bit more how the configuration options are used in the code generator, to see what exactly needs to be done for option B. I am ok with going in that direction as a safer path if we decide so