Implement better buffer abstractions in Silicon Labs code

[bzbarsky-apple]

Problem

Silicon Labs code has abstractions for reading/writing buffers (things like emberAfPutInt8uInResp and emberAfGetInt16u) but these are not perfect in terms of abstracting away the storage. The emberAfPut*InResp ones are probably OK as long as the caller does not desugar larger things into bytes by hand, since they already update the written length themselves. The emberAfGet* APIs have an obvious problem: they don't indicate how many bytes of buffer they consumed, so the consumer has to make assumptions about how much to advance the read pointer. This is OK if the storage is fixed-width, but if we move to TLV or CBOR that won't really work.

Proposed Solution

I think we should do several things, probably after we have landed all the clusters we want:

1. Introduce a struct of some sort that encapsulates "the buffer we are reading right now" and maintains at minimum the current read position and how many more bytes can be read.
2. Switch all the places to-be-read buffers are passed through (command dispatch, command implementations as needed, etc) to this new struct. This would include the emberAfGet* APIs, which would be fixed to advance the read pointer themselves so consumers don't have to.
3. Introduce Get and Put APIs for higher-level constructs like "attribute id", not just integer sizes. Under the hood this can call the appropriate integer thing, but make it clearer what we're really reading/writing.

We may also want to rename the APIs to nix "ember", and possibly move them into code that's built as part of libCHIP, so encoder/decoder code (which is built into libCHIP) can use them.

@woody-apple @CamWms @bhaskar-apple @rwalker-apple

[issue-label-bot]

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.94. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.