API enters idle/sleep state causing first request delay

[kamilsi]

It has been observed that after a period of no traffic, the first database-backed request (for example, randomizing a patient) takes about 3 seconds, while the second identical request takes about 0.8 seconds. This pattern repeats after quiet spells.

Hypotheses:
The API creates a global PostgreSQL pool during startup without configuring any keep-alive, idleTimeout, or minSize settings. As a result, the runtime depends on the defaults of pool::dbPool and the database server. After a quiet spell, the next request must re-open a connection, which matches the observed multi-second delay.
Randomization requests immediately hit the pool through dplyr::tbl() and DBI::dbGetQuery(), so the first call after idle pays the reconnection cost while subsequent calls reuse the warm session and complete quickly.
Audit logging relies on pool::localCheckout() as well, so the same idle or keep-alive behavior can affect other endpoints unless the pool remains warm.

There should be a facility to change this behavior for time-sensitive users.