loggerd: eliminate recursion from handle_encoder_msg

[deanlee]

Changes:

1. Refactored handle_encoder_msg: Moved the encoding packet writing logic to a new function, write_encode_data,
2. Eliminated Recursive Calls: Replaced recursive calls within handle_encoder_msg with direct calls to write_encode_data for writing queued packets in the new segment. This change prevents potential crashes by handling queued packets safely, even if they are out of sync with the encoderd.

3. Improved Memory Management: Replaced raw pointers with std::unique_ptr for managing Message objects, improving memory safety.
4. Removed Redundant Parameter: Removed the service.name parameter from handle_encoder_msg, as it duplicates the re.publish_name value already available through the re parameter.

Resolves #28857

[github-actions]

This PR has had no activity for 9 days. It will be automatically closed in 2 days if there is no activity.

[github-actions]

This PR has been automatically closed due to inactivity. Feel free to re-open once activity resumes.

[github-actions]

This PR has had no activity for 9 days. It will be automatically closed in 2 days if there is no activity.

[github-actions]

This PR has been automatically closed due to inactivity. Feel free to re-open once activity resumes.

[github-actions]

This PR has had no activity for 9 days. It will be automatically closed in 2 days if there is no activity.

[adeebshihadeh]

Can we break this up at all?

[github-actions]

This PR has had no activity for 9 days. It will be automatically closed in 2 days if there is no activity.

[adeebshihadeh]

@deanlee I'm ready to merge this PR, but it still doing too many things. can we break it up? ideally we just have one targeted PR at removing the recursion, then a followup that does the other things.

[deanlee]

Done. I’ve simplified this PR by removing all other changes, leaving only the refactor that moves the encoded data writing logic from handle_encoder_msg to the new function write_encoder_data. The function body is nearly identical to the original code.

[maxime-desroches]

@deanlee Do you have a way to reproduce memory leaks or weird behaviors when loggerd/encoderd get out of sync ?

[deanlee]

If the encoderd restarts while loggerd is logging and there are encoded messages already queued in loggerd's queue, it will recursively call handle_encoder_msg. Due to the invalid segment_id of the queued items, the messages will be re-queued without being flushed to the new segment, resulting in infinite recursive calls when the system is out of sync.

The current recursive approach adds unnecessary complexity and introduces synchronization bugs without offering real benefits.

I'll look into adding a new test case later to capture this synchronization issue.