Pull Logging and Logic Improvements

[BLuedtke]

Alright, the "Improve Logging" branch has grown to incorporate a bit more than just logging improvements.

• I added some Validation improvements outside of request handlers.
• Some formatting fixes

The biggest changes are in the request handlers. I moved the validation around such that they follow a pattern:

1. Parse form data
2. Validate form data, Log ERR if validation fails
3. Validation succeeded -> Log request start
4. Processing request
5. Log that processing has finished (or failed, respectively).

The "log request start" is also outfitted with data about request parameters, such that one can trace after the fact what request is which, if there are multiple trains/users active. Furthermore, the "log request finished" is the exact same as the "log request start" if possible, just with a "finished" at the end. This makes it relatively easy to trace when a request came in and when it was finished.

Since I already had to touch most of the handlers and some related functions, I made some adjustments to them, mostly regarding validation and formatting. There are also some notes I made on areas of the codebase that may need some change but where we should really discuss it first.
This is a bit of a bigger change, but IMO prepares us to tackle the API rework.

[BLuedtke]

This concludes the changes I wanted to make before testing.

[BLuedtke]

Known mistakes:

• driver release train: sometimes printed with "train", sometimes with "train id"
• request route: "from" parameter in "finished" log is the route id, but should be the source signal.
• wrong log when setting interlocker leads to segmentation fault

[BLuedtke]

Tested the correctness of the logs for all endpoints except for monitor/pure getters.
log2.txt
log2-clientside.txt

For pure getters, i.e. those handlers that only log on the level LOG_NOTICE, I tested that they respond as expected, but I did not check the correctness of their logs (not enough time).

The previous commit resulted from this testing.

[eyip002]

For human-readability, I think it is necessary to add - start because it's very hard to remember the message format to look for until you reach the message with - finish (then you can backtrack to the corresponding "start" message.

---

Should be tested with the web clients to make sure they can still parse the server responses.

[BLuedtke]

For human-readability, I think it is necessary to add - start because it's very hard to remember the message format to look for until you reach the message with - finish (then you can backtrack to the corresponding "start" message.

I agree. Also: Should it be "finish" instead of "finished"?

Somewhat related: Should the error messages after - start, that also indicate end of processing, have something like - abort? It'd clarify that it's the end of processing at the cost of (probably) more line breaks. On the other hand, an error log at the end of processing is not really "aborting", so not sure if that term is suitable.

[BLuedtke]

The ci is failing due to some build setup issue, specifically when trying to install libgnutls. Will also have to look at that at some point.

[BLuedtke]

Pipeline works again, added apt update before any step where apt packages are installed.
In the long term (regarding the ci pipeline), we may also want to switch from ubuntu-latest to a fixed ubuntu version (currently ubuntu-latest seems to be Jammy/22.04).

[eyip002]

For the code documentation, think about whether libbidib's doxygen setup could be reused.

[BLuedtke]

For the code documentation, think about whether libbidib's doxygen setup could be reused.

I'd cover that in a future issue/pr, not in this one

[BLuedtke]

#127 (comment) somehow I cannot answer to that comment/change request. Not sure why. I'm adjusting the message in a way similar to the proposed message.