Geo: Create separate models for different registries

What does this MR do?

One day Geo::FileRegistry will be split up in separate table. This change already defines separate models. So the code can operate like they are separate tables, using a bit of hackery STI.

Technical details

This, in fact, generates identical SQL queries:

expect(described_class.all.to_sql).to eq(Geo::FileRegistry.attachments.to_sql)

That succeeds and generates:

SELECT "file_registry".*
FROM "file_registry"
WHERE "file_registry"."file_type" IN ('attachment',
                                      'avatar',
                                      'file',
                                      'import_export',
                                      'namespace_file',
                                      'personal_file',
                                      'favicon')

So I don't see any downsides on adding these models.

What are the relevant issue numbers?

Path towards: https://gitlab.com/gitlab-org/gitlab-ee/issues/10067

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated via this MR
• Documentation reviewed by technical writer or follow-up review issue created
• Tests added for this feature/bug
• Tested in all supported browsers
• Conforms to the code review guidelines
• Conforms to the merge request performance guidelines
• Conforms to the style guides
• Conforms to the database guides
• Link to e2e tests MR added if this MR has Requires e2e tests label. See the Test Planning Process.
• EE specific content should be in the top level /ee folder
• For a paid feature, have we considered GitLab.com plans, how it works for groups, and is there a design for promoting it to users who aren't on the correct plan?
• Security reports checked/validated by reviewer