Add primary key to elasticsearch_indexed_projects

What does this MR do?

Related to #270090 (closed)

Promotes the unique index from elasticsearch_indexed_projects into a primary key. In GitLab.com production, this table has zero rows. It is in-use a small amount of self-managed installations, but table size is estimated to be < 1000 rows.

Since the table is small enough, it seems relatively safe to transactionally promote the existing index inline, rather than add the complexity of creating a new NOT NULL replacement column, migrating data, etc.

The DELETE is supported by the index, if there are any existing rows where project_id IS NULL: https://explain.depesz.com/s/DEOK

The model already has the primary key explicitly set to use project_id, so this should not alter app behavior: https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/elasticsearch_indexed_project.rb#L7

Migration up

rails db:migrate:up VERSION=20201201161655
== 20201201161655 AddPrimaryKeyToElasticSearchIndexedProjects: migrating ======
-- execute("DELETE FROM elasticsearch_indexed_projects\nWHERE project_id IS NULL\n")
   -> 0.0010s
-- execute("ALTER TABLE elasticsearch_indexed_projects\nALTER COLUMN project_id SET NOT NULL,\nADD CONSTRAINT elasticsearch_indexed_projects_pkey PRIMARY KEY USING INDEX index_elasticsearch_indexed_projects_on_project_id\n")
   -> 0.0008s
== 20201201161655 AddPrimaryKeyToElasticSearchIndexedProjects: migrated (0.0019s)

Migration down

rails db:migrate:down VERSION=20201201161655
== 20201201161655 AddPrimaryKeyToElasticSearchIndexedProjects: reverting ======
-- add_index(:elasticsearch_indexed_projects, :project_id, {:unique=>true, :name=>"index_elasticsearch_indexed_projects_on_project_id"})
   -> 0.0033s
-- execute("ALTER TABLE elasticsearch_indexed_projects\nDROP CONSTRAINT elasticsearch_indexed_projects_pkey,\nALTER COLUMN project_id DROP NOT NULL\n")
   -> 0.0007s
== 20201201161655 AddPrimaryKeyToElasticSearchIndexedProjects: reverted (0.0042s)

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team