feat: partition assets into multiple tenants

[kushsharma]

This is a breaking change, all existing applications using compass will have to modify their contract to include a namespace. The elasticsearch index strategy has been changed, all the data will need to be re-indexed again. The user flow would be as follows:

• Client sends a request to compass for creating a new namespace. Compass will create an entry in postgres and depending on if this tenant is shared or dedicated an index and an alias will be created in elasticsearch.
• Subsequent calls to compass that relates to an asset will need to pass the namespace id.
• Client can Get/List all registered namespaces. One thing to note is, as part of the migration step, compass creates a default namespace to avoid the hassle of bootstrapping compass use-case.

Changes are made based on design discussion at #208. API changes are available in raystack/proton#246

To enforce multi-tenant restrictions at the database level, I have used Row Level Security. RLS requires Postgres users used for application database connection not to be a table owner or a superuser else all RLS are bypassed by default. That means a Postgres user that is migrating the application and a user that is used to serve the app should both be different.

To create a postgres user

CREATE USER "compass_user" WITH PASSWORD 'compass';
GRANT CONNECT ON DATABASE "compass" TO "compass_user";
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO "compass_user";
GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO "compass_user";
GRANT ALL ON ALL FUNCTIONS IN SCHEMA public TO "compass_user";

ALTER DEFAULT PRIVILEGES IN SCHEMA "public" GRANT SELECT, INSERT, UPDATE, DELETE, REFERENCES
                ON TABLES TO "compass_user";
ALTER DEFAULT PRIVILEGES IN SCHEMA "public" GRANT USAGE ON SEQUENCES TO "compass_user";
ALTER DEFAULT PRIVILEGES IN SCHEMA "public" GRANT EXECUTE ON FUNCTIONS TO "compass_user";

A middware for grpc looks for x-namespace-id header to extract tenant id if not found falls back to default namespace. Same could be passed in a jwt token of Auth bearer.

[coveralls]

Pull Request Test Coverage Report for Build 4533387823

Warning: This coverage report may be inaccurate.

We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

• 745 of 989 (75.33%) changed or added relevant lines in 34 files are covered.
• 27 unchanged lines in 10 files lost coverage.
• Overall coverage decreased (-1.9%) to 84.14%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
internal/server/v1beta1/server.go	3	4	75.0%
internal/store/postgres/discussion_repository.go	10	11	90.91%
internal/server/v1beta1/lineage.go	3	5	60.0%
internal/store/elasticsearch/discovery_repository.go	36	38	94.74%
internal/store/postgres/tag_repository.go	28	30	93.33%
core/namespace/namespace.go	3	6	50.0%
internal/server/v1beta1/search.go	9	13	69.23%
internal/store/postgres/user_repository.go	39	44	88.64%
internal/server/v1beta1/comment.go	16	22	72.73%
internal/server/v1beta1/discussion.go	10	16	62.5%

Files with Coverage Reduction	New Missed Lines	%
internal/server/v1beta1/type.go	1	86.21%
internal/store/elasticsearch/discovery_repository.go	1	82.29%
internal/store/elasticsearch/discovery_search_repository.go	1	83.41%
internal/store/postgres/user_repository.go	1	84.26%
internal/store/postgres/asset_repository.go	2	76.63%
internal/server/v1beta1/discussion.go	3	89.16%
internal/store/postgres/postgres.go	3	61.85%
internal/server/v1beta1/comment.go	4	84.96%
internal/server/v1beta1/asset.go	5	81.63%
core/user/service.go	6	84.91%

Totals
Change from base Build 4511593465:	-1.9%
Covered Lines:	5475
Relevant Lines:	6507

---

💛 - Coveralls

[pyadav]

We should not allow changing state till automation is not available for migrating one state to another.

[kushsharma]

Agree so I have not added namespace update call in cli but I feel that instead of leaving this behind in the API, we can still have it to make it complete. What do you think?