Migrate from `norman` to `steve` `cloudcredentials`

[richard-cox]

RFD: https://github.com/SUSE/rancher-architecture/pull/42
r/r issue: rancher/rancher#49401
design doc: linked in https://github.com/SUSE/rancher-architecture/pull/42#pullrequestreview-4013470374

• Listing Cloud Credentials
  • CC's are fetched for the signed in user. Admins however see all CC's. We should improve the UX for admins to help them understand if the CC is one of theirs or not (we could add a user column, but we would need to go out and fetch user info to avoid just showing an id)
    • see field.cattle.io/creatorId annotation
  • as per other steve resources, state comes from metadata.state
  • we will not fetch secrets, but CC's should contain public information we can show
    • CCs return public info given dyunamic schema publicFields definition OR the CC's own spec.visibleFields (useful for extension owners who don't setup dynamic schemas, lots more info in design doc)
• Deleting a CC that has been used with a cluster should result in an error presented to user with a reasonable explanation
  • I'm not sure we bubble up the error message of the delete action anywhere. we should do so, probably in the notification center via growl(?)
• Deleting a CC will offer a new 'force' option that ignores any blocker of a cluster connected to the CC
  • TBD (UX) We could choose to make this an option only in the warning message from above
• Creating/Editing a CC
  • CC is for a core Provider (in r/d)
    • UI currently has built in forms. We need to update them
  • CC is for a Provider supported by a UI Extension
    • We should continue to support hooks for them (they provide a vue component to show)
  • CC is not sore, or supported by a UI Extension
    • Provider has a cc schema with resourceFields (TBD)
      • We should continue to dynamically create the form from these fields
      • For example
        • Previously
          • Given /v3/schemas/cloudCredential resourceFields.amazonec2credentialConfig.type: amazonec2credentialconfig
          • Schema with fields is /v3/schemas/amazonec2credentialconfig
        • Now
          • Given /v1/management.cattle.io.dynamicschemas/credentialconfig contains a reference to take ec2 provider to ec2 cloud credential config schema
          • Resource with fields is /v1/management.cattle.io.dynamicschemas/amazonec2credentialconfig
          • TBD (all) For BYO providers this is an additional step previously brought in via node/clsuter driver
      • More details in the old way are https://github.com/SUSE/rancher-architecture/pull/42#discussion_r2895455114
    • Provider does not have cc schema
      • We do best effort things with node config resourceFields
  • General Create Changes
    • CCs are now namespaced
      • if not in lockdown mode (see below) create in same ns we default to when creating v2prov clusters (i.e. fleet-default)
      • TEST: Ensure this process works for standard users who have not previously created a cluster (and might not have access to fleet-default)
      • if lockdown mode (see below) create cc with namespace option. we should restrict these to those with backing fleet workspaces.
      • TBD: What happens if they create a CC in something other than fleet-default and then go on to create a cluster (would always default to fleet-default)
        • https://github.com/SUSE/rancher-architecture/pull/42#pullrequestreview-4013470374
• Model Changes
  • data now stored in a credentials map instead of a funky credentialConfig prop
  • Provider type is now a standalone prop, we don't have to do funky thinks to extract it from properties ending with a magic phrase (see configKey)
• NEW FEATURE - Locked down mode
  • A new feature flag will be introduced to lockdown cc creation to only admins, who can delegate them to specific users
  • delegation is basically done by creating the CC in a namespace backed by a fleet workspace
  • So when FF is enabled users should be able to create CC in one of those namespaces
  • NOTE - we don't allow users to create clusters in namespaces other than fleet-default, can cause issues, see above

[eva-vashkevich]

#8523 ideally should be fixed by this change