feat(api): push geocoding info on rdv-solidarités user upsert

[Holist]

Lié à https://www.notion.so/gip-inclusion/Sectorisation-rdvsp-Am-liorer-la-secto-en-remplissant-le-g-ocoding-quand-on-cr-un-usager-dans-rdv-2b05f321b60480a3846bc63a1c6fce1f
Fait suite à betagouv/rdv-service-public#6337 coté rdvsp

Description

• Inclut post_code, city_code et city_name dans le payload envoyé à RDV-Solidarités lors de la création/mise à jour d'un user, en s'appuyant sur les champs déjà délégués à address_geocoding.
• Mapping du naming côté RDV-I (city) vers celui de l'API RDV-S (city_name).

[aminedhobb]

Merci @Holist d'avoir attaqué ce sujet 🙏 .
Je me demande si ça répond forcément vraiment au problème initial (qui était que le payload de la requête synchrone à la géo API côté rdv-sp n'était pas toujours bien formatté).

Par contre je vois pas mal de problèmes potentiels à essayer de synchroniser nos deux systèmes sur ce point, surtout que côté rdv-i on récupère la géolocalisation de manière asynchrone.
Par exemple avec ce changement que tu fais, si on change l'adresse de l'usager côté rdv-i l'adresse sera changée côté rdv-s mais on enverra l'ancienne géolocalisation (puisqu'elle n'aura pas eu le temps de se mettre à jour). Ça peut créer de nouveaux problèmes à mon avis.
Mais aujourd'hui on a pas un peu le même problème dans l'autre sens ? Si l'adresse de l'usager est renseignée sur rdv-s, et qu'on la change sur rdv-i, c'est les anciennes valeurs de geolocalisation qui resteront stockées pour cet usager côté rdv-sp ?