Update system/SystemPacketBuffer to use uint32_t(instead of uint16_t) for several fields to accommodate large payloads

[pidarped]

Feature description

Currently, SystemPacketBuffer uses uint16_t for a lot of its internal and public parameters. These would need to be updated to accommodate large payload sizes when operating over TCP.
Internally, fields such as alloc_size uses uint16_t.
APIs such as MaxDataLength() and AvailableDataLength() return uint16_t. These need to use uint32_t when handling large sized buffers that go beyond uint16_t limits.

Platform

core

Platform Version(s)

No response

Anything else?

No response

[bzbarsky-apple]

Shouldn't it just use size_t for the APIs?

[pidarped]

@bzbarsky-apple, I had considered using size_t but on second thoughts felt that uint32_t might be better. Since the max size of the field in the TCP payload is set to 4 bytes, everything in the code, from processing to storage, should be dictated by that, IMO.
Changes have to be made to both the API arguments as well as internal storage. Using uint32_t at all the relevant places seems to require less static_casts. Also, size_t, being not the same in all architectures(8 bytes in Linux standalone) might pose weird problems(during casting in and out of it) in some edge cases, that I would want to avoid.

[pidarped]

Fixed by #33001 in master.