Dependency between subsystems at the DB layer

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

Change abandoned by Rodrigo Duarte (<email address hidden>) on branch: master
Review: https://review.openstack.org/445505
Reason: abandoning for now...

Is this the only place where we have foreign key relationships between the identity backend and something else? If so, maybe this isn't as big of a deal since it's all required for a federated deployment. If you're deploying keystone with federation, you'll need to have a sql backend of some kind to store information required for federation. With the development of shadow users, it is also expected that a separate identity backend (e.g. sql) is available to persist the local (federated) user references.

Unassigning due to inactivity.

This is also an issue with the resource backend and the identity backend, which causes us to drop the pluggability of the resource backend.

Reviewed: https://review.opendev.org/687753
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=c4d60977881ac2f014dc6e2eaaba37892f075266
Submitter: Zuul
Branch: master

commit c4d60977881ac2f014dc6e2eaaba37892f075266
Author: Colleen Murphy <email address hidden>
Date: Wed Oct 9 16:30:33 2019 -0700

    Drop project.id foreign keys

    In 2bd88d30 we added a new column domain_id to the user table to
    deduplicate the domain_id columns in the local_user and nonlocal_user
    tables, and at that point made the user.domain_id column a foreign key
    referencing the project.id column. This is a problem that led to
    3d46c8a5 in which we removed the ability for the resource driver to be
    pluggable, since we had linked two sql backends together and made them
    reliant on one another.

    This commit removes the foreign key constraint from the user table and
    the identity_provider table. For the user table, the sqlalchemy model
    never reflected this schema so we don't need to change the model. For
    the identity_provider table, we need to update the model. In both cases,
    we already enforce, at the manager layer, the constraint that the
    domain_id needs to reference a real domain ID[1][2], so we do not need
    to rely on this constraint at the database layer.

    [1] https://opendev.org/openstack/keystone/src/commit/43142e4470df976a459a1a2e95cfb163afc42893/keystone/identity/core.py#L935
    [2] https://opendev.org/openstack/keystone/src/commit/43142e4470df976a459a1a2e95cfb163afc42893/keystone/federation/core.py#L73-L77

    Partial-bug: #1672713

    Change-Id: I7c068e350811e22622d1f1e7d8b0a55d4d7cab11