Improve the integration test suite

The current integration test framework has a few limitation:
- It uses a polling approach
- It requires putting a network up to update
- It only test the APIs

Here's how it could be improved:

## Check what is written to the DB in addition to the APIs

Ultimately we want to check that the DB is correctly written, and not just trust the API.
That is not trivial to do, as this DB lives in a container.

## Uses a pushing approach

Instead of checking every X seconds, uses the stream from the API, or `inotify` on the DB, to check for update.

## Provide a "preprocessor" for the data

We want to keep the current approach (sending the JSON file) but currently it requires us to specify hard-to-get parameters (signature) as well as irrelevant parameters, or parameters that might require manual modification (time).
So providing the test "definition" along with the actual tests will make updating the tests trivial (the dev just have to run the generator) while still keeping the tests independent.

Those 3 points can be implemented independently. The 3rd one probably has the highest ROI at the moment.

Start by reviewing the current integration test framework, its JSON input flow, and how the database runs in a container. Compare the three independent improvement areas, with the preprocessor identified as the highest-ROI starting point; done means the chosen approach has clear, repeatable checks beyond the current API-only polling workflow.

Written by the indexing model from the issue text.