[BACKEND][ETL] Use spire_update_update value instead of created value

[rv2931]

J'ai noté que tous les process ETL se basent sur la date de création des records
L'interrogation est faite au niveau API sur une liste de mmsi et l'API renvoie une position systématiquement même si cette position/ces infos n'a pas été mise à jour depuis plusieurs jours. Cela engendre de un surplus de temps de traitement qui me semble à première vue un peu inutile, et j'ai pas vérifié mais potentiellement des création de position aussi (à vérifier)

Je propose que comme on fait uns interrogation toutes les X minutes, la dernière interogation étant consultable via les TaskExecutions, on prennent en compte non pas la date de création de la ligne dans spire_ais_data qui est systématiquement créé même pour une position qui n'a pas bougé depuis plusieurs jours mais d'utiliser la spire_ais_data_spire_update_statement éliminant de fait toutes les positions qui ont été mis à jour il y a plus de X minutes et qui n'ont pas eu d'autres mise à jour entre temps
Faudra créer un index sur cette même colonne aussi pour améliorer les perfs
Je vais faire quelques tests mais sur le principe vous y voyez un souci particulier ?
@SebM42 @njouanin @marthevienne

[rv2931]

J'ai qu'on prend le timestamp "spire_ais_data.position_timestamp" pour remplir "vessel_position.timestamp"
Comme position_timestamp vient du bateau, faut le considérer comme non fiable à mon avis.
J'ai noté plusieurs cas dont l'heure position_timestamp renvoyée par le bateau est non seulement loin de spire_update_statement mais surtout bouge dans le temps.

Par exemple le mmsi 227380000 pour spire_update_statement compris entre le 01/07/2024 et le 02/07/2024, le vessel_position.timestamp est dans un premier temps "2024-06-11 01:20:04+02" puis est mis à jour ensuite pour revenir à une heure dans la "bonne" tranche demandée. Pour moi c'est typique du temps que mettrait un GPS pour se resynchroniser et donc resyncrhoniser l'heure.
Mais cela montre bien qu'il ne faut pas faire confiance à l'heure des bateaux mais plus à celle de détection AIS qui à priori est spire_update_statement.
De l'autre côté ça montre aussi qu'il ne faut pas faire confiance aux heures bateaux pour faire des filtres car finalement, il suffirait que le bateau ait une heure complètement décalée par rapport à l'heure courante pour qu'on exclue ses positions si on mettait en place un traitement par lot
spire_update_statement me paraît quand même être le plus fiable à prendre en compte d'une manière générale