Handle slightly more complex `clouds.yaml` formatting

[sc68cal]

Each region of a cloud can have its own unique auth_url key, so that the schema appears like the following:

---
clouds:
    mycloud:
        identity_api_version: 3
        endpoint_type: public
        image_format: raw
        auth:
            user_domain_name: 
            project_domain_name: 
            username: 
        regions:
            - name: Region 1
              values:
                auth:
                  auth_url: 
            - name: Region 2
              values:
                auth:
                  auth_url: 
            - name: Region 3
              values:
                auth:
                  auth_url: 
            - name: Region 4
              values:
                auth:
                  auth_url: 
            - name: Region 5
              values:
                auth:
                  auth_url: 

See the following issue for background

https://github.com/terraform-providers/terraform-provider-openstack/issues/405

[sc68cal]

It's not well documented, but in the openstacksdk there is this example, and a bullet point about how "region settings override cloud settings"

https://github.com/openstack/openstacksdk/blob/9d1b8a2a781e66c8451ca67c87dc17ca4b93a908/doc/source/user/multi-cloud-demo.rst#much-more-complex-cloudsyaml-example

[sc68cal]

The older os-client-config that openstacksdk superceded has this to say:

https://docs.openstack.org/os-client-config/latest/user/configuration.html#per-region-settings

[sc68cal]

I'm fairly motivated to fix this since this is blocking other work for me, so I plan on pushing some patches and getting familiarized with this repo today.

[jtopjian]

@sc68cal Sounds good. Please let me know if you need any help.

[sc68cal]

@jtopjian do you guys have a mailing list/slack/IRC channel you use for contributors? I have a couple questions - or is it just via issues in this repo?

I'm trying to avoid making any seriously large backwards incompatible changes - but if each region has its own set of overridden values, there could be Cloud objects with collections of AuthOptions for each region of the cloud, and I don't know how disruptive that would be.

[jtopjian]

@sc68cal Discussion is just via issues.

If backwards-incompatible changes are required, then that's fine.

One thing to keep in mind, though, is that we'll want to pinpoint exactly where in the OpenStack Python client code the region supports these options. The documentation and sample examples provided show that it should be a feature, but for Gophercloud implementations, we always fall back to proof in the code since that's the only way to be 100% sure the feature exists.

[sc68cal]

Agree - I have a TODO on my end to find that behavior in the openstack SDK, since I'd be looking at its behavior to ensure my patch does the same