feat: connection pool metrics in admin server

[steve-chavez]

Closes #1526

curl localhost:3001/metrics

# HELP pgrst_schema_cache_query_time_seconds The time it took to query the schema cache in seconds
# TYPE pgrst_schema_cache_query_time_seconds gauge
pgrst_schema_cache_query_time_seconds 1.3591601e-2
# HELP pgrst_schema_cache_loads_total The total number of times the schema cache was loaded
# TYPE pgrst_schema_cache_loads_total counter
pgrst_schema_cache_loads_total 1.0

# HELP pgrst_db_pool_max Max pool connections
# TYPE pgrst_db_pool_max gauge
pgrst_db_pool_max 20.0
# HELP pgrst_db_pool_waiting Requests waiting to acquire a pool connection
# TYPE pgrst_db_pool_waiting gauge
pgrst_db_pool_waiting 0.0
# HELP pgrst_db_pool_available Available connections in the pool
# TYPE pgrst_db_pool_available gauge
pgrst_db_pool_available 1.0
# HELP pgrst_db_pool_timeouts_total The total number of pool connection timeouts
# TYPE pgrst_db_pool_timeouts_total counter
pgrst_db_pool_timeouts_total 0.0

Added a couple of schema cache load metrics plus 4 pool metrics.

References

• Hikari Pool metrics (ref1, ref2).
• WebSphere Application Server pool metrics
• generic-pool-prometheus-exporter
• pgbouncer metrics https://github.com/prometheus-community/pgbouncer_exporter

[steve-chavez]

There's a problem for counting the total amount of created pool connections and solving #3214. Just opened nikita-volkov/hasql-pool#43.

[steve-chavez]

Will finish #3214 on another PR.

For now this can close #1526

[steve-chavez]

Tried to appease codecov but there's a couple of warnings that cannot be cleared. Will merge.

[steve-chavez]

Was thinking how to document this.. so we have three observability elements: logs, metrics and traces.

Logs and metrics are obvious. But what about the execution plan and the server-tming? I believe those should go into traces because:

Traces track the end-to-end behavior of a request as it moves through a distributed or microservice system.
https://thenewstack.io/observability-working-with-metrics-logs-and-traces/

Running traces takes too much time and consumes too many resources to trace every request an application receives.
https://www.techtarget.com/searchitoperations/tip/The-3-pillars-of-observability-Logs-metrics-and-traces

server-timing obviously fits that description. The execution plan, not completely.. but it looks it fits on traces for now.

---

Originally I was thinking to merge the Architecture and Observability pages, since each of our major components have some observability. But I'll keep Observability in its own page for SEO.