Improve tlog writer: log when arm

[joaoantoniocardoso]

Expected behavior:

1. The tlogwriter driver now accepts a when argument, which can be either always or while_arm.
2. The default value for this argument is always to match the same behavior from mavlink-router, which is only configurable via conf-file, as described here. For this reason, this patch introduces a major behavior change.
3. If the passed path is a folder that doesn't exist, it will try to create the entire path.
4. When operating as while_arm, it will start a new file every time the vehicle changes from disarmed to armed, following the same file name format as mavlink-router. On the other way around (when the vehicle changed from disarmed to armed), it closes the file.
5. When operating as while_arm, the system_id and component_id from which it monitors the heartbeats can be configured from endpoint arguments, falling back to the same behavior as mavlink-router: it gets the system ID from the first heartbeat sent by an autopilot (component id 1).

• Tested locally
• Tested on the vehicle w/ Navigator

Closes #54.

[patrickelectric]

It would make the logic simpler if this relies on #119 to see if the vehicle is armed

[joaoantoniocardoso]

It would make the logic simpler if this relies on #119 to see if the vehicle is armed

Yeah, I thought about that when implementing the arm detection, but I've chosen to work directly with the bytes to avoid the impact of converting every message to mavlink (which is basically parsing the message twice).

[patrickelectric]

It would make the logic simpler if this relies on #119 to see if the vehicle is armed

Yeah, I thought about that when implementing the arm detection, but I've chosen to work directly with the bytes to avoid the impact of converting every message to mavlink (which is basically parsing the message twice).

But this will already be done by the control PR nevertheless

[joaoantoniocardoso]

It would make the logic simpler if this relies on #119 to see if the vehicle is armed

Yeah, I thought about that when implementing the arm detection, but I've chosen to work directly with the bytes to avoid the impact of converting every message to mavlink (which is basically parsing the message twice).

But this will already be done by the control PR nevertheless

I know, but the control does not parse every message. I'm working on a better approach for translating between the lib's types without preparing.