drivers: can: shell: sending CAN FD frames with non-even DLC <=> nbytes relationship sends garbage at frame data end

[henrikbrixandersen]

Describe the bug
Sending CAN FD frames with non-even DLC <=> nbytes relationship using the Zephyr CAN shell sends garbage at frame data end.

To Reproduce
Steps to reproduce the behavior:

1. Using the Zephyr CAN shell, send a CAN FD frame with 10 data bytes defined on the shell command line (e.g. can send can0 -f 040 00 11 22 33 44 55 66 77 88 99)
2. Notice that the CAN shell will (correctly) enqueue a CAN frame with a DLC of 9 meaning 12 bytes to be transferred. This is due to CAN FD not supporting arbitrary frame data lengths.
3. Notice, however, that the CAN shell will incorrectly use the number of bytes in the output labelled DLC (e.g. enqueuing CAN frame #3 with standard (11-bit) CAN ID 0x040, RTR 0, CAN FD 1, BRS 0, DLC 12)
4. Using a CAN analyser, notice that the last two bytes of the CAN FD frame payload contains garbage.

Expected behavior

• The shell output should print the correct DLC (not the number of bytes).
• The shell should zerorise the CAN frame to ensure no garbage bytes are sent at the end of the frame.

Impact
Annoyance, confusion.

Logs and console output

uart:~$ can mode can_loopback0 normal loopback fd 
setting mode 0x00000005
uart:~$ can filter add can_loopback0 040
adding filter with standard (11-bit) CAN ID 0x040, CAN ID mask 0x7ff
filter ID: 0
uart:~$ can start can_loopback0 
starting can_loopback0
uart:~$ can send can_loopback0 -f 040 00 11 22 33 44 55 66 77 88 99
enqueuing CAN frame #0 with standard (11-bit) CAN ID 0x040, RTR 0, CAN FD 1, BRS 0, DLC 12
CAN frame #0 successfully sent
(00000)  --       040  [12]  00 11 22 33 44 55 66 77 88 99 7b ab 

Environment (please complete the following information):

• OS: Linux
• Toolchain: Zephyr SDK 0.16.5-1
• Commit SHA: 3a3f25c