Expose DDF schema for a provider when asking using OPTIONS + type

[skateman]

Extracted the providers_options into a separate method and only returning when the type isn't set for the /api/providers. If the type param is set in a request, the API will try to append the data-driven-form schema if specified under the data.provider_form_schema key. This schema can be used by the UI to render the right form that contains all the required info for adding a provider of the given type.

// OPTIONS api/providers?type=ManageIQ::Providers::Amazon::CloudManager
{
  ...
  "data": {
    ...
    "provider_form_schema": {
      "title": "Configure AWS",
      "fields": [
        {
          "component": "text-field",
          "name": "role",
          "type": "hidden",
          "initialValue": "ec2"
        },
        {
          "component": "text-field",
          "name": "region",
          "label": "Region"
        },
        {
          "component": "text-field",
          "name": "ec2_username",
          "label": "Access Key"
        },
        {
          "component": "text-field",
          "name": "ec2_password",
          "label": "Secret Key",
          "type": "password"
        }
      ]
    }
  }
}

If the type argument cannot be safely constantized into a subclass of ExtManagementSystem or the provider has no DDF specified it will raise an BadRequestError. The request without the type parameter behaves like the OPTIONS request before this change.

Example of the DDF schema in the amazon provider: ManageIQ/manageiq-providers-amazon#551
Parent issue: ManageIQ/manageiq#18818

@miq-bot add_reviewer @lpichler
@miq-bot add_reviewer @abellotti
@miq-bot add_label enhancement, ivanchuk/no, hammer/no

cc @Hyperkid123, @martinpovolny, @agrare

[Hyperkid123]

@skateman is there way to get auth_type for these fields? If so it would be great if we could scope the fields. Something like name: authentication.default.userid. This would basically copy the request payload format necessary for API. It would also make it easier for providers with multiple auth types. Then we would have API payload like this:

{
"authentication": {
    "default": {
      "name": "foo",
      "password": "bar"
     },
    "remote": {
      "name": "foo",
      "password": "bar"
    }
  }
}

[skateman]

@Hyperkid123 I'm just exposing the stuff @agrare is defining in ManageIQ/manageiq-providers-amazon#551, if I'd do what you want here, we would end up with the same if-else-case 🍝 we have in ems_common.

[Fryguy]

ManageIQ/manageiq#19120 has been merged.

[skateman]

@Fryguy we don't depend on the validation backend here, this PR could go in right now without any backend modifications...but thanks, I'll take a look at it.

[miq-bot]

Checked commit skateman@2c98c6f with ruby 2.4.6, rubocop 0.69.0, haml-lint 0.20.0, and yamllint 1.10.0
2 files checked, 0 offenses detected
Everything looks fine. ⭐