Standardize PostgreSQL Checks

The goal of this issue is to discuss some of the QoL changes to checks using SQL.

May not be a priority, but standardizing checks with SQL in them will go a long way in helping with portability and contributions.

Some of the benefits we'll see from this are:

• Running all checks using the same connection
• Client agnostic check data (SQL Statement) - Not worrying about gitlab-psql, or other binaries being available means the check won't be constrained this way (Though there may be some checks we don't want to run against external databases)
• Easier to add more checks once this is done(?)
• Cleaner checks with stronger DRY powered foundation

What this may look like

Instead of having a check that's gitlab-psql -someoption "SELECT COUNT..." | grep something or similar, we'd ideally be able to use abstractions, looking more like check_constraint_[found|notfound] <constraintname>

A task that generates a list of statements based on checks and their metadata, and executes/evaluates them all in gone go.

Related to #77 - Maybe this belongs in a separate issue, but this could help overcome the "where do I run this" part of the equation.

I've mentioned this a few times, but as long as we have a Rails environment, we can stop worrying about connection strings and other details - I've successfully used the toolbox pod to run checks via an experiment of mine, but other options are:

• gitlab-rails runner style checks (Slow, but maybe not so much if we run everything using the one connection)
• Ad-Hoc rake task:

time gitlab-rake -f /tmp/quick.rake "q[SELECT * FROM users LIMIT 5]"  1> /dev/null

real	0m0.814s
user	0m0.603s
sys	0m0.196s

• gitlab-rails dbconsole --db main (Not all that different from the runner approach)

@bcarranza I may have missed a few things, but I created a draft so I didn't forget this