Refactor `platform` table to enable custom domains

[MoralCode]

in order to support flexible platform support, the current platform table needs to not act like an enum (which it currently is) and instead act more like a form of data storage for specific user defined platforms (instances) of forges that are supported by CollectOSS.

Currently this table is referred to in these tables:

• message
• issue event
• pr event
• pr review

there may be a platform frontend api too but i cant find it

in all cases this just refers to the platform_id, which essentially is the same platform type flag that ContributorUUID uses.

This issue is for schema planning and migration to a better platform table that can adequately support the parent issue

[MoralCode]

Additionally, (cross references notwithstanding) it seems like this table is likely only useful during collection, and should be in the operations schema

That, oddly, makes migration easy, as a new table can be spun up in that location independently. once the old referring tables are divorced from the foreign keys and are instead using those referring columns to denote the platform type (via an enum in the codebase *), that would allow the old platform table to be removed entirely.

Now all we need is the schema for it

* not in the database because they are hard to migrate in postgres.

[MoralCode]

To get this rolling, id like to create a new table in the operations schema

id like to call it instances (or similar) to more clearly define its purpose.

The new table needs (first draft):

• platform_type (the same integer being referred to by the tables mentioned above) - this would denote which API implementation gets used for the platform
• platform_name - user-defined name for the platform, i.e. "my cool forgejo instance"/"homelab"
• date_added - might be useful for sorting i guess
• domain name - the domain name to use for the platform. This will be used to support Add option to use Github Enterprise API for api key checks #110 and/or custom gitlab/forgejo instances
• enabled - denotes whether to collect for that platform (up for debate as to whether we can add this later, this idea was from the linked issue discussed below)

[MoralCode]

Comparison with related issue

while #71 is a decent start for this, that issue was written with a different vision for the platform table in mind (i.e. continuing using it like an enum) which differs from the current one.

I see this issue as being the modern replacement of/superseding that issue.

This is because I believe the _platform_s (AKA APIs) that are supported should be defined in the code. It makes no sense to allow a new platform to be added with a database table because it would ALSO require code changes to support that platform's APIs anyway - so why not have both in the same place.

this is why, what #71 calls "platform", i call "platform type", an identifier managed in code, alongside/integrated with the platform implementations.

this is also why id prefer the term "instances" for the table above (at least internally), since platform seems like it can be interpereted both ways

key limiting:

#71 suggests we add a "platform features" column to the worker_oauth table where we store API keys. This would be for storing key pseudo-platforms (IE: the different request limits for each key type - gor github, these would be rest and graphql) these values would be used by keyman for rate limiting.

For the purposes of this issue, I would call this "rate limit groups" instead, and i think they belong in the internal implementation, alongside other information like the platform name/type, rather than in a DB table, since they are basically fixed information that changes with the API (and should therefore live in the implementation code).

key storage:

I generally agree with #71 on this last point. worker_oauth needs to be the only place we store API keys.