Introduce some isolation behaviour to organizations

Introduce some isolation behaviour to organizations such that at least one feature cannot work between 2 organizations (this only applies to groups that have been added to an organization)

One possible first example will be group group sharing /organizations/bigcompany => Can't add the /gitlab-org as a member of any of my projects or groups

The objective of this issue is to show user experience of isolation. We should be able to demonstrate through the UI what happens if a user tries to violate a cross-organization constraint and how we'd implement the enforcement of such constraints in the backend.

We also might be able to take inspiration from existing constraints like the fact that you can't add an issue to an epic in a different namespace hierachy.

Possible technical solution with foreign keys

This may be extracted to a followup issue depending on how we decide to implement this.

Foreign keys could be used to enforce the constraint that no foreign keys ever cross an organization boundary. For any 2 tables connected by foreign keys (eg. group_group_links ... FOREIGN KEY (shared_with_group_id) REFERENCES namespaces(id) ...) we could add an extra foreign key constraint like:

ALTER TABLE ONLY group_group_links
    ADD CONSTRAINT fk_rails_2b2353ca49_organization FOREIGN KEY (shared_with_group_id, organization_id) REFERENCES namespaces(id, organization_id) ON DELETE CASCADE;

ALTER TABLE ONLY group_group_links
    ADD CONSTRAINT fk_rails_d3a0488427_organization FOREIGN KEY (shared_group_id, organization_id) REFERENCES namespaces(id, organization_id) ON DELETE CASCADE;

This will work if we can add organization_id column to both tables and we consider that all existing data has organization_id = NULL so this constraint should be valid for all existing tables.

Since the group_group_links table has only 1 organization_id this would prevent sharing groups outside of an organization. This same approach could apply to any foreign keys.

If generalized, and if we could add organization_id to every table, then it would be possible to be certain that no data is related to any other table outside of the organization.

Generalizing this would have to take loose foreign keys into consideration which may be tricky because these were never built to actually enforce the foreign key constraint on insertion but only for cleaning up deletes.