Inconsistent use of tenant_id, tenantId, default_project_id across identity drivers for the User object/ref

A fix for this bug should un-skip tests introduced in https://review.openstack.org/#/c/42826/

By default the tenant_id is not stored by the LDAP backend (or in the case of v2.0 tenantId). This appears to be an intentional choice as there is no attribute mapping on the back end. There is also inconsistency in the use of tenant_id, tenantId, and default_project_id across the different drivers and versions of API.

The solution will be as follows:
* Provide a mapping for LDAP attributes to set/store the default_project_id
* SQL, make default_project_id a full column in the identity backend
* Put in translation code to return "tenantId" for v2.0 gets on the user, and "default_project_id" for v3 user gets
* Put in translation code to normalize the backend to the correct values.

LDAP will still, by default, not store the default_project_id, however, the option to configure it to store the data will be available. Unless keystone's configuration defaults are changed, it will not be returned nor stored (in the LDAP identity driver) via use of the RESTful api or the keystoneclient.

Fix proposed to branch: master
Review: https://review.openstack.org/46207

Reviewed: https://review.openstack.org/46207
Committed: http://github.com/openstack/keystone/commit/dda19c3977cd12bd6694a3bc932539ca2b08aee9
Submitter: Jenkins
Branch: master

commit dda19c3977cd12bd6694a3bc932539ca2b08aee9
Author: Morgan Fainberg <email address hidden>
Date: Thu Sep 12 00:11:45 2013 -0700

    Cleanup of tenantId, tenant_id, and default_project_id

    This patchset normalizes the use of tenantId, tenant_id, and
    default_project_id across the Identity backend. This includes
    making default_project_id no longer part of the "extra" json blob
    on the user object and migrating all "tenantId" "tenant_id" and
    "default_project_id" into the new column (SQL).

    In the LDAP driver, None is set as the mapping for
    default_project_id. This means that use of default_project_id with
    LDAP Identity will require an explicit mapping to be defined by the
    cloud operator.

    "default_project_id" remains (by default) configured to be in the
    "ignore" attributes for the LDAP driver, so 'tenantId' and
    'default_project_id' will not be saved on the user_object during
    update or create unless Keystone is explicitly configured to do so.

    closes-bug: 1219739
    closes-bug: 1226475
    related-bug: 1201251
    Change-Id: I07f9dfe111646884ac5efd42fc8c2974188b3b94

Thanks for Margan