fix(db): monte db/init fichier par fichier et coupe la telemetrie

Monter le dossier ./db/init sur /docker-entrypoint-initdb.d remplacait le
dossier de l'image au lieu de s'y ajouter. Les trois scripts d'init livres
par timescaledb-ha disparaissaient sans aucun message : creation de
l'extension dans template1, reglage par timescaledb-tune, et installation de
timescaledb_toolkit. Verifie au demarrage : le dossier ne contenait que nos
deux fichiers, et timescaledb_toolkit etait absent des bases.

Monter chaque fichier separement retablit l'ordre attendu, verifie dans les
journaux : 000, 001, 010, puis 100 et 110.

TIMESCALEDB_TELEMETRY passe a off par defaut : l'image envoie sinon des
statistiques d'usage a Timescale, ce qui ne va pas pour un deploiement
on-premise.

db/README.md

@@ -12,23 +12,28 @@ Les migrations du schema applicatif expose par l'API vivent dans
 
 ## `init` ne rejoue jamais
 
-Le dossier est monte sur `/docker-entrypoint-initdb.d`, dont PostgreSQL ne joue le
+Ces scripts sont montes sur `/docker-entrypoint-initdb.d`, dont PostgreSQL ne joue le
 contenu qu'a la toute premiere initialisation, quand `PGDATA` est vide. Modifier ou
-ajouter un script ensuite reste sans effet sur une base existante :
+ajouter un script ensuite reste sans effet sur une base existante : il faut detruire
+le volume, ce que fait `make db-reset`.
 
-```bash
-docker compose down -v && docker compose up -d db
-```
+L'image apporte ses propres scripts dans ce dossier, et ils comptent :
 
-L'image joue d'abord ses propres scripts (`000_`, `001_`, `010_`), dont un
-`CREATE EXTENSION IF NOT EXISTS timescaledb_toolkit CASCADE` qui installe `timescaledb`
-au passage dans `postgres`, `template1` et la base applicative. Nos fichiers sont
-numerotes a partir de `100` pour passer apres, quelle que soit la locale de tri.
+| Script | Origine | Role |
+|---|---|---|
+| `000_install_timescaledb.sh` | image | Cree l'extension dans `postgres`, `template1` et la base applicative, et fixe `timescaledb.telemetry_level`. |
+| `001_timescaledb_tune.sh` | image | Lance `timescaledb-tune` sur la memoire et les CPU vus par le conteneur. |
+| `010_install_timescaledb_toolkit.sh` | image | Ajoute `timescaledb_toolkit`. |
+| `100-extensions.sql` | ce depot | Declare explicitement les extensions attendues. |
+| `110-test-database.sql` | ce depot | Cree `enervision_test`, attendue par la suite de tests du backend. |
 
-| Script | Role |
-|---|---|
-| `100-extensions.sql` | Declare explicitement les extensions attendues. |
-| `110-test-database.sql` | Cree `enervision_test`, attendue par la suite de tests du backend. |
+D'ou deux contraintes dans `docker-compose.yml`. Nos fichiers sont **montes un par un**,
+et non par leur dossier : un montage de `./db/init` sur `/docker-entrypoint-initdb.d`
+remplacerait le dossier de l'image au lieu de s'y ajouter, et ferait disparaitre les trois
+scripts ci-dessus sans le moindre message. Ajouter un fichier ici impose donc d'ajouter
+une ligne la-bas. Et leur numerotation commence a `100` pour passer apres `010`, y compris
+en locale C ou un prefixe a deux chiffres se trierait avant.
 
-Comme un bootstrap peut toujours avoir ete saute, c'est `/api/v1/health/ready` qui fait
-foi : la sonde refuse de repondre 200 si l'extension n'est pas chargee.
+Comme un bootstrap peut toujours avoir ete saute, deux gardes le rattrapent :
+`/api/v1/health/ready` repond 503 si l'extension n'est pas chargee, et la premiere
+revision Alembic refuse de s'appliquer.