Add check selection api to the server

[arbulu89]

This PRs implements one of the 1st components to remove consul usage from checks service.
It stores the selected checks in the new Postgres database, and offers the API endpoints to do so externally. This 2nd things will be needed from the runner, as it needs to get the currently selected check ids. The created service code will be used in the cluster web handler as well, to remove the current consul code.

The SelectedChecks information will go in a new table with the next struct:

• ID, the selected resource ID. By now, this will be the cluster id, but it will scale if we add other concepts checks
• SelectedChecks, a comma separated list of checks as a string. This copies the current exact type. We can store it as an array if needed, I just migrated the current type for easiness sake

I have more or less the subsequent code ready (adapt the runner and server sides), but I preferred to keep the PR small to improve the review process

[dottorblaster]

A tiny comment, but I think we are ready to merge after this gets addressed or clarified

[dottorblaster]

LGTM

[arbulu89]

@dottorblaster @fabriziosestito I have updated the SelectedChecks type to a list of strings, which aligns better the purpose of the attribute, the list of selected checks.
Could you have a new look? The change comes in: 753a389

PD: I have been forced to create the new JSONSelectedChecks struct, as swagger doesn't work with pq.StringArray

[rtorrero]

@arbulu89 LGTM, thanks!

[dottorblaster]

Looks quite good to me, good job @arbulu89!

[nelsonkopliku]

Good stuff!
My OCD would prefer a slightly different setup for tests. But that's not a blocking. 🚀

[nelsonkopliku]

I would probably refactor to use testsuites and maybe split Scenarios into smaller test functions, but this just works as fine! 💪

[arbulu89]

Yes, initially I thought the same. But as it already had pretty complete tests (test 200, 404, 500), I just followed the same approach.
Nothing against using suites or smaller functions :D

[fabriziosestito]

LGTM, we might start thinking of dividing api in files or subpackages as it is growing a lot.

[arbulu89]

LGTM, we might start thinking of dividing api in files or subpackages as it is growing a lot.

Agree! I would create an api folder within web so we have all the code in there.
I will do it in one of my next PRs, as I'm still adding some few more api code