Switch message header encode/decode input lengths to uint16_t.

[bzbarsky-apple]

This will remove some impedance mismatches around lengths later on.

Problem

Message header encode/decode functions take length as size_t, whereas everything else, pretty much, uses uint16_t.

Summary of Changes

Just use uint16_t like elsewhere.

[github-actions]

Size increase report for "esp32-example-build" from 960cfe0

File	Section	File	VM
chip-wifi-echo.elf	.flash.text	20	20

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-wifi-echo.elf and ./pull_artifact/chip-wifi-echo.elf:

sections,vmsize,filesize
.debug_line,0,60
.flash.text,20,20
.debug_loc,0,12

[rwalker-apple]

this kind of cast makes me wonder if we're going the wrong direction with this. maybe we should isolate the uint16_t-limitations in PacketBuffer and in DM protocol details

[bzbarsky-apple]

this kind of cast makes me wonder if we're going the wrong direction with this

The biggest problem here is that C's integer-promotion rules for arithmetic are kind of dumb. If those were unsigned int, the difference would also be unsigned int, but a difference of two uint16_t gets promoted to int. Without -Wconversion it's not an issue, of course, because the narrowing conversion is silent then... I wish compilers were smarter here; a sufficiently smart compiler can in fact prove that len - payloadlen is a valid uint16_t value based on those two lines of code, and could avoid warning about the "narrowing" conversion. Ah, well.

We could switch a bunch of this stuff to size_t, but then we run into the need to do a bunch of casting and/or dynamic checks needed when indexing into PacketBuffers.

I guess I could change the in-progress code I have for #2914 to take size_t-sized buffers, not uint16_t-sized, so we can keep accepting size_t-sized things in the Decode methods here. We get impedance mismatches that way too, though....