LwM2M: any retransmitted block #0 is forwarded to upper layer with no warning

[marco85mars20]

Describe the bug

Two issues:

• when the post-write callback receives the payload of block #0, it often differs from the actual block size. This might not be a bug since block transfers can complete successfully, however, RCF 7959, section 2.3 specifies that:
  Update: as expected, this is not an issue; the first 5B of the block 0's payload are actually a TLV data struct providing information about the actual size of the data being transferred (feels a bit redundant, but it must have its reasons).

<s>The block size implied by SZX MUST match the size of the payload in bytes, if the M bit is set.
(SZX does not govern the payload size if M is unset).

• in case of retransmission of block #0 due to late ACK, the post-write callback is called for every consecutive block #0 received without being notified about it (as described in LwM2M block-wise transfer: add callback to notify upper layer that a transfer has restarted #71269)

Logs printed from the post-write callback:

• The first 2 blocks have the same size (smaller than the actual block size), ie. the second one is a duplicate of Block 0
• The last block reported as block 733 is, in fact, block 732, and it causes the total size received to exceed the size of the data transferred

/* block num is a counter incremented at every block received by my custom post-write callback */
[00:02:30.217,926] <dbg> lwm2m_dfu: firmware_block_received: received 1019 B, total: 1019/751444 B, last_block:0, block num: 0  (0%)
[00:02:30.219,970] <dbg> lwm2m_dfu: firmware_block_received: received 1019 B, total: 2038/751444 B, last_block:0, block num: 1  (0%)
[00:02:30.423,461] <dbg> lwm2m_dfu: firmware_block_received: received 1024 B, total: 3062/751444 B, last_block:0, block num: 2  (0%)
[00:02:30.619,415] <dbg> lwm2m_dfu: firmware_block_received: received 1024 B, total: 4086/751444 B, last_block:0, block num: 3  (0%)num: 4  (0%)

[..]

[00:04:55.706,665] <dbg> lwm2m_dfu: firmware_block_received: received 1024 B, total: 748534/751444 B, last_block:0, block num: 730  (99%)
[00:04:55.903,350] <dbg> lwm2m_dfu: firmware_block_received: received 1024 B, total: 749558/751444 B, last_block:0, block num: 731  (99%)
[00:04:56.117,889] <dbg> lwm2m_dfu: firmware_block_received: received 1024 B, total: 750582/751444 B, last_block:0, block num: 732  (99%)
[00:04:56.320,251] <inf> lwm2m_dfu: firmware_block_received: received 1024 B, total: 751606/751444 B, last_block:0, block num: 733  (100%)

Expected behavior
Since Tokens cannot be used to trace a block-wise transfer (#57165), it is not possible to detect if a Block #0 has already been processed, for this reason, I believe the only option is to pass the block-number to the post-write callback.
However, tokens could still be useful for detecting duplicates of block 0.

[nordicjm]

This issue lacks required information such as what zephyr version you are using, can you fill in the required information from https://raw.githubusercontent.com/zephyrproject-rtos/zephyr/main/.github/ISSUE_TEMPLATE/001_bug_report.md by updating the post?