Default domain to support Identity API v2

With the introduction of domains in Identity API v3, all projects (tenants) and users must be owned by a specific domain. However, the v2 API is not domain-aware.

Example issues:

- When an admin user creates a new tenant or user on the v2 API, which domain is that resource owned by according to the v3 API?
- When an admin user lists all tenants or users in the system, which resources are returned according to the v3 API? v2 clients won't understand the domain_id attribute
- (with domain-scoped user names in v3) If a user attempts to authenticate with a username, which domain should that user exist in?
- (with domain-scoped project names in v3) If a user attempts to authorize with a project by name, which domain should that project exist in?

To ease the migration path from v2 to v3, it would be useful if all existing projects & users were explicitly assigned a domain for use on v3, and all v2 operations were assumed to apply to that one domain. Therefore, all of the questions above can be answered in the scope of this 'default' domain.

For deployments using the SQL-based identity driver, a data migration could create the default domain (id='default', name='Default'), and then attach all existing projects & users to it (if any exist).

A new configuration variable, `default_domain_id`, could be used to allow users of all identity backends to specify which the domain upon which operations on the v2 API should apply. This variable could default to simple `default`. LDAP deployments would need to ensure that this domain_id exists if they intend to maintain support for v2 API users.

The value of the `default_domain_id` should have no impact on the v3 API, with one exception. That is: API users should not be allowed to delete this domain. DELETE /v3/domains/{default_domain_id} should result in a 403 Forbidden. Actually deleting this domain should be a carefully orchestrated manual process, as configuration changes would also be involved (e.g. removing the v2 API pipeline from the deployment) to avoid breaking the deployment.

Projects moved out of the default_domain_id on the v3 API would then become inaccessible from the v2 API, etc.

The following pairs of calls would then be equivalent:

  GET /v2.0/users
  GET /v3/users?domain_id={default_domain_id}

  GET /v2.0/tenants
  GET /v3/projects?domain_id={default_domain_id}

  POST /v2.0/tokens {'auth': {'projectName': 'foobar'}}
  POST /v3/auth {'auth': {'projects': [{'name': 'foobar', 'domain_id': 'default'}]}

  etc