Keystone to honor the "domain" attribute mapping rules

This blueprint proposes Keystone to honor the "domain" attribute mapping rules,
and adds a versioning method to the attribute mapping schema used by identity federation deployments.

Problem Description
===================
Currently, Keystone identity provider (IdP) attribute mapping schema only
uses the "domain" attribute mapping as a default configuration for the domain
of groups being mapped; groups can override the default attribute mapping
domain by setting their specific domain. However, there are other "elements"
such as user and project that can also have a domain to define their location
in OpenStack.

An operator when reading the attribute mapping section and seeing the schema
for the attribute mapping definition, can be led to think that the domain
defined in the mapping will also apply to users and projects. However, that is
not what happens.

Proposed Change
===============
First of all, to facilitate the development and extension concerning attribute
mappings for IdPs, we changed the way the attribute mapping schema is handled.
We introduced a new option called `schema_version`, which defaults to "1.0".
This attribute mapping schema version will then be used to control the
validation of the attribute mapping, and also the rule processors used to
process the attributes that come from the IdP. So far, with this patch, we
introduce support to the attribute mapping schema "1.1", which enables
operators to also define a domain for the projects they want to assign users.
If no domain is defined either in the project or in the global domain
definition for the attribute mapping, we take the IdP domain as the default.

Thus we extended Keystone identity provider (IdP) attribute mapping
schema to make Keystone honor the `domain` configuration that we have on it.
Currently, that configuration is only used to define a default domain for
groups (and then each group there, could override it). It is interesting to
expand this configuration (as long as it is in the root of the attribute
mapping) to be also applied for users and projects.

Attribute mapping schema
--------
The current schema defined at keystone/federation/utils.py#MAPPING_SCHEMA:

.. code-block:: json

    {
    "type": "object",
    "required": ['rules'],
    "properties": { ...}
    "definitions": { ...}
    }

Adding the `schema_version` attribute:

.. code-block:: json

    {
    "type": "object",
    "required": ['rules'],
    "properties": {
            "rules": {...}
            "schema_version": {
                "name": {
                    "type": "string"}
                }
    }
    "definitions": { ...}
    }

Validations
-----------
We will validate the `schema_version` against all existing/possible versions of the field. Therefore, if it is not within the already defined version, and error is thrown.

If no `schema_version` is presented, then the version used is `1.0`

API impacts
-----------
None

Assignee(s)
-----------

Primary assignees:
 - Rafael <email address hidden>

Other contributors:

Work Items
----------

1) Implement proposed changes in Keystone [1]_

 - Create a new mapping schema

 - Create new processors for the proposed changes

 - Implement validations and unit tests

 - Update documentation

Dependencies
============

None

References
==========

.. [1] https://review.opendev.org/#/c/739966/