Wait for postgres properly

[alxndrsn]

TODO

• test whether not_in_recovery check is necessary vs SELECT 1
• document startup phases clearly

---

This PR contains work foundational to:

• Update postgres to v18 central#1385

---

PostgreSQL startup comes in (at least) N phases:

TODO document this

---

Closes getodk/central#2141
Closes getodk/central#2194

What has been done to verify that this works as intended?

• ran locally
• ci
• ran a few hundred times in ci without issue, with both pg14 and pg18
• ran 2,000 times in ci without issue, using both pg14 and pg18
  • https://github.com/getodk/central-backend/actions/runs/34943311766
  • https://github.com/getodk/central-backend/actions/runs/34943311829
  • https://github.com/getodk/central-backend/actions/runs/34945552174
  • https://github.com/getodk/central-backend/actions/runs/34945552350
  • https://github.com/getodk/central-backend/actions/runs/34945580935
  • https://github.com/getodk/central-backend/actions/runs/34945580939
  • https://github.com/getodk/central-backend/actions/runs/34945595783
  • https://github.com/getodk/central-backend/actions/runs/34945596015
  • https://github.com/getodk/central-backend/actions/runs/34945818909
  • https://github.com/getodk/central-backend/actions/runs/34945818944

(Each run is 200 attempts. Jobs/workflows were retried when failures were due to docker image download or docker API 502.)

Why is this the best possible solution? Were any other approaches considered?

Waits better than before. Should be quick on quick machines, and slow on slower ones.

How does this change impact users? Describe intentional behavior changes from code updates. What are the regression risks?

No immediate effect, but this approach can (and likely should) be applied in the central repo to prevent issues for self-hosters.

Does this change require updates to the API documentation? If so, please update docs/api.yaml as part of this PR.

No.