Store checks metadata in the DB instead of ARA

[arbulu89]

Refactor the checks metadata catalog storage, to use the Database instead of ARA.
In order to do so:

• We have a new table named checks, which stores the checks catalog data with the check ID, and the rest of the data as payload. I used this approach, as I expect changes in this structure, so having a json payload makes things easier to avoid migration issues, etc. The changes I expect might be like: add a new premium field, split the expected values to other column or table, etc. This is an open discussion: Do you prefer the usage of fixed table structure or json payload mode
• Checks service code to get and store the metadata in the database
• A new API call to post the metadata api/checks/catalog, (ApiCreateChecksCatalogtaHandler) to create the catalog data.
• Update the runner to use the new post endpoint instead of ARA

PD: Maybe there are some ARA leftovers over there. I will remove everything once we have the checks posting finished too

[nelsonkopliku]

Green light from my side 🟢 🚀

[nelsonkopliku]

ahah funny jsonb stuff. At least it works eheh. Will keep this in mind, thanks

[fabriziosestito]

lol at that font ligature ->>

[arbulu89]

This is postgres specific unfortunately, but it works hehe

[fabriziosestito]

I feel we will need to soon to split entity and models, here it is done already with checkRaw being the persisted entity and check being the model

[arbulu89]

Just to understand better your wording:

• entity DB related struct
• model API related struct
  Is this correct?
  Do we have some other internal structure to manage data better? I ask this, as we store a lot of data as jsonb which needs to be unmarshalled at some point.

[stefanotorresi]

This looks good, but I see a few problems coming up, which are not specific to this PR, but they are becoming more relevant as we add API endpoints.
The main problem I think is that we need a dedicated package for everything related to the web API, as it has its own data models and potentially will have its own business logic, which should be segregated from the web frontend part. This is not to be done now, of course, but let's keep this in mind.
As I mentioned below, for example, we are mixing models a little bit, and the distinction is not super clear to me.