Merge Mutex and memory fixes

[BLuedtke]

This PR addresses 2 areas:

1. Mutex: Up until now, the "grabbed_trains_mutex" is sometimes used when reading/writing the grabbedtrains array. This means there is a lot of potential for bugs due to concurrent/conflicting r/w access. Affected areas are mainly the handler... files that use the grabbed_trains array directly.
2. Memory: The parsers are currently leaking memory all over the place. I analyzed this with address-sanitizer and adjusted them accordingly. Whilst adjusting the parsers, I also streamlined some of the unnecessarily long ifs into if-elses. Additionally, across most handlers, I added checks for the returns of malloc and strdup. I.e., checking if the memory allocation succeeds.

Open TODOs that should be discussed/resolved/moved before merging this PR:

• handler_admin line 265: handler_admin doesn't have access to the same constant (TRAIN_DRIVE_TIME_STEP in particular) like handler_driver has, but it is needed here. Maybe move these constants to a header?
• handler_driver line 894: For releasing a train, the speed is first set to 0. We then wait until the speed actually becomes 0. Only then is the train released. But what if some other thread sets the speed to something != 0 directly after it is set to 0 here? We can't keep the mutex locked, as that prevents progression in the engine container.

Furthermore, whilst some manual testing has been performed, more rigorous use/testing is needed.

I also suggest to squash commits upon merging, as it's, well, quite a lot of experimental small ones.

[BLuedtke]

The failing build seems to be a regression in the area of config_get_array_string_value, specifically if it's about main_segments. Will investigate.

[BLuedtke]

last_scalar in parser_util was freed a bit too early, causing the parser to act slightly differently in some of the callbacks. Tests now run fine on my machine.

[eyip002]

Suggested tests:

• [x] Execute every command available in the Python client: check the returned messages and physical state
• [x] Try every option available in the web clients (driver, controller, client, game): check the returned messages and physical state
• [ ] Run the physical test cases
• [x] Check server logs

[BLuedtke]

What does "physical test cases" refer to? There are none for cli, only for bidib. The test script that uses the python client isnt any better than me testing with the python client directly in this case.

Anyway, I just had a long test session. Tested all web pages (normal + game) and the full python client. test notes 2023-08-04.md

Only one issue was querying the reverser state. need to check that in more detail and compare against other branches.

Interesting: I think I found a much simpler reason for why we had trains going the wrong way, but I need to do some more checks to confirm...

[BLuedtke]

Alright, I can't get the reverser state if no train is sitting on the Kehrschleife. But this is the same as on the master branch. If a train is on there, I get the info as intended. So that works, and concludes my testing.

[eyip002]

Should probably make physical test cases based on sample_test_script.sh for switching points and signals, and running a train.

The reverser query behaviour doesn't sound normal. Are you able to get the monitor to print "on" and "off" for the reverser state?

Is BiDiB Wizard able to read the reverser state?

[BLuedtke]

I will open a new issue for the reverser problem, as it happens on the master branch too.

[BLuedtke]

The other problem I found is that automatic route driving get's the direction wrong in a very specific situation with the Kehrschleife. Maybe the two problem are interlinked.