fix(socket_can_receiver): support variable-length CAN FD frames

[xmfcx]

From @knzo25 's branch in https://github.com/knzo25/ros2_socketcan/commits/feat/continental_fd/

Related PR:

• chore(autoware.repos): add ros2_socketcan and change transport_drivers fork autoware#5008

Summary

This PR fixes an issue in the SocketCanReceiver class where it incorrectly assumed that all CAN FD frames would be the maximum size (64 bytes). This assumption caused errors when handling shorter frames, as observed with SRR520 frames.

The fix ensures that the receive_fd method can properly handle variable-length CAN FD frames by dynamically calculating the expected frame size based on the actual data length (frame.len). It also introduces additional safety checks to prevent corrupted or incomplete frames from being processed.

Changes

• Adjusted the logic in receive_fd to handle CAN FD frames shorter than 64 bytes.
• Added a calculation for expected_length based on the fixed header size and the variable data length.
• Improved error handling to ensure that corrupted or incomplete frames are rejected.

Additional Improvements

• Added a check to ensure that the frame length (frame.len) does not exceed the CAN FD maximum allowed data length (64 bytes).
• Refactored the error handling to provide more detailed messages in cases of failure.

[mojomex]

See the above suggestion

[knzo25]

@mojomex
Sorry but can you check it this commit addresses your concern?

[mojomex]

LGTM!

[mojomex]

Tests are failing because CPPlint enforces <= 100 character lines with at least 2 spaces between code and comments.

[mojomex]

LGTM!

[mojomex]

@xmfcx it seems like I don't have write access in this repo, so I don't count towards the required reviews. Could you review/merge it?

[xmfcx]

This PR makes significant changes in how the can frames are parsed.

Was this tested on real hardware?

[knzo25]

@xmfcx
Previously to this I had zero experience with can fd so that is why I never sent a PR to the upstream.
This code has been tested using Continental's SRR520, but we do not have any other devices to test.

As explained in the code, the problem is that the original implementation seemed to only accept fd frames of the max size (64 bytes).
SRR520 has some fd frames that are quite shorter, making the main branch complain.