Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

Ahead of the addition of some new tests.

Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

Right now these are effectively duplicates of the tests for
GetSupportedMicroversions, which is also expanded here to test against
the version documents of other services, but that will change shortly.

Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

In commit f28c963, we added support for
discovering API versions. To do this, we added a dependency on the
'version' and 'min_version' headers, which are used by services with
microversion support to document the maximum and minimum API versions
supported, respectively. However, not all services support API
microversions: services like Glance and Designate use API versions as a
signal of a new feature (or, in Glance's case, as a signal that a
feature is not enabled), others like Keystone just support a single
version, while Neutron does its own thing with API extensions [1]. Given
this fact, relying on these fields is a mistake.

Instead, we should be relying on the 'id' field. Per the api-sig
guidelines [2], this should be the API major version [3]. We continue
parsing the microversion-related headers, since it will be useful later
on if/when we want to do versioned discovery.

[1] https://that.guru/blog/api-versioning-in-openstack/
[2] https://specs.openstack.org/openstack/api-sig/guidelines/discoverability.html
[3] The studious among you may notice that the api-sig guidelines
    indicate that the maximum API microversion should be exposed via the
    'max_version' header. However, in practice, virtually everyone uses
    'version' instead. Why? Who knows. Best to just take these things on
    the chin and move on with our lives.
[4] The term "major version" is a bit loaded. Consider Nova: at the time
    of writing, it exposes two "major versions": v2.0 and v2.1. v2.0
    does not support microversions. v2.1 does. For v2.1 you therefore
    also have microversions to content with and at the time of writing
    it supports a minimum microversion of 2.1 and a maximum microversion
    of 2.100 (no 'v' prefix here). Normalizing these as we've done here
    gives us a major version of 2, a minor version of 1, a major maximum
    microversion of 2, a minor maximum microversion of 100, a major
    minimum microversion of 2, and a minor minimum microversion of 1 🤯.

Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

While the expected format of these documents is defined by a spec [1],
most services do things slightly differently. Here, we add support for
the Keystone and Barbican-style documents, which embed version objects
inside another object with a single 'values' key, like so:

  {"versions": {"values": [{"id": "v3.14", ...}]}}

And the Magnum-style document, which doesn't envelope individual version
objects at all:

  {"id": "v2", ...}

These are in contrast to the format used by Nova, Cinder etc.:

  {"versions": [{"id": "v2", ...}]}

We also add support for 'max_version' key, which is used by Magnum and
is what the spec actually recommends.

[1] https://specs.openstack.org/openstack/api-sig/guidelines/discoverability.html

Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

The 'vlan-transparent' extension is now enabled by default [1]. This is
highlighting a bug in the aforementioned test: namely, that we are
trying to update an attribute which is read-only [2]. Remove the update
step of the job and fix the test.

[1] openstack/neutron@11ff4f2
[2] https://github.com/openstack/neutron-lib/blob/fd011c955dfae1072555c69b6ba742b85f041736/neutron_lib/api/definitions/vlantransparent.py#L49

Signed-off-by: Stephen Finucane <stephenfin@redhat.com>