Run GHA against `main` periodically to catch API changes and/or previously unknown features

[mvglasow]

Checks for #33 failed, but apparently for reasons related to the API itself rather than the changes in the PR (see https://github.com/bundesAPI/autobahn-api/pull/33#issuecomment-1575137487 for details). In this case it is because of the API not supplying the content type (any more?), as well as an enum value we were previously not aware of.

Our main challenge is that we’re checking against a reverse-engineered API, which may change its behavior or reveal previously unknown features any time, and against data which changes frequently. For this reason it might be a good idea to run GHA on main periodically. If that fails all of a sudden, it’s a sign we missed something, or the API changed.

I have a similar use cases for milestones and road numbers used in a traffic service for Poland. There the main point is to find road number/milestone combinations which are not in OpenStreetMap yet, which won’t become apparent until they’re mentioned in a traffic message. Ideally we would want to check each and every traffic message, but that is not feasible. Instead, I chose to work on a representative set of traffic messages.

I poll the API at 1:30, 9:00, 13:30 and 18:00 each day, which should get me roadworks during the night (1:30), particular situations during peak hours (9:00 and 18:00) as well as daytime situations (13:30). The main difference is that the API I run this against has a single endpoint for all motorways, expressways and national roads in Poland, whereas Autobahn-API has one endpoint per road. So we might need a representative set of not only time points, but also of roads – preferably roads which are prone to getting traffic reports – but I would rather start with running the same job we run on a PR four times a day, and refining it later on.