CoAP mesage abstraction
This crate defines interfaces for readable and writable CoAP messages. Thus, it allows CoAP servers (and possibly clients) to be written independent of the actual CoAP library that is used to serialize and deserialize the messages to the protocol.
It also provides some simple types that can help users and library implementers to not repeat the same registered names all again.
The readable message types are designed with minimal fallability -- for example, iterating over the options can not raise a "premature end of message" style error. This encodes the concept that having a message type implies validity of the message. It is backed by currently used libraries (RIOT's Gcoap, jnet-coap) performing the necessary validation steps when constructing message objects.
Whether this is a good idea remains to be seen.
Libraries that insist on minimizing the cycles spent parsing can opt to present invalid messages in truncated form, but need to be aware that this has important security implications.
Iteration item for option values
A message that needs to have its code, any options in ascending order and its payload set in that very sequence.
A message that allows later manipulation of a once set payload, and later truncation.
Marker trait that indicates that the sequence of calling set_code, add_option and set_payload is not fixed. The sequence of calls only has meaning in that later set_code and set_payload calls override earlier ones, and that add_option on the same option number are stored in their sequence.
Marker trait that indicates that ReadableMessage::options are produced in ascending sequence.