Statistik-Endpunkte um created_at, updated_at erweitern

Hintergrund

Die GET /statistics/...-Endpunkte werden vom usage-statistics-data-service verwendet, um die Daten in die Reporting-Datenbank zu importieren. Dabei wird mit paginierten Listen gearbeitet und es wird versucht:

• einen inkrementellen Import zu gewährleisten, also bei einem Import-Lauf nur diejenigen Tupel abzurufen, die seit dem letzten erfolgreichen Import neu hinzugekommen sind
• bei veränderlichen Bestandsdaten sollen die Tupel immer wieder dann neu importiert weren, wenn sich das Bestandsdatum seit dem letzten Import verändert hat. (In der Reporting-Datenbank wird mit Primärschlüsseln und Upserts gearbeitet, um diese krude Form des Updates umzusetzen).

Die Endpunkte erlauben dafür ein Paging über startDate, endDate und offset. Leider wird in den Responses aber nicht das Datum herausgegeben, auf das sich startDate und endDate beziehen. Weil Import-Vorgänge auch an beliebigen Stellen abbrechen können, ist es dem usage-statistics-data-service daher nicht möglich, festzustellen, bis zu welchem Zeitpunkt ein Import stattgefunden hat. Es ist also nicht möglich, ein startDate sinnvoll festzuetzen, um keine Tupel des "Streams" zu überspringen.

Akzeptanzkriterien

• Jeder Statistik-Endpunkt gibt für jedes Tupel ein updated_at zurück, was den Datumswert enthält, auf den sich startDate und endDate jeweils beziehen. (Dies kann bei immutable Rows auch created_at sein)
• Jeder Statistik-Endpunkt gibt zusätzlich created_at zur besseren Nachverfolgbarkeit heraus
• Bei den Enpunkten für Events wird event_log.created_at für das Paging verwendet