feat(coap): Access storage

[chrysn]

Description

This is a demonstrator for storage access through CoAP.

Quoting the updated README:

$ pipx run --spec 'aiocoap[all]' aiocoap-client coap://10.42.0.61/complex --credentials client.diag
# CBOR message shown in Diagnostic Notation
{"re": 4, "i": -3}
$ pipx run --spec 'aiocoap[all]' aiocoap-client coap://10.42.0.61/config --credentials client.diag -m PUT --payload '"Fjord"' --content-format application/cbor
$ pipx run --spec 'aiocoap[all]' aiocoap-client coap://10.42.0.61/counter --credentials client.diag -m DELETE

Issues/PRs references

Replaces #350.

Open Questions

• How do we want to have that in the code base?

Change checklist

• I have cleaned up my commit history and squashed fixup commits.
• I have followed the Coding Conventions.
• I have performed a self-review of my own code.
• I have made corresponding changes to the documentation.

[chrysn]

The way things go through minicbor or serde_cbor is a bit of a mess still, partially because I picked the best version instead of the one with least code.

With twittner/minicbor#4, things could become more consistent.

[chrysn]

@kaspar030 asked me for a usability report; here goes:

1. Having a system wide storage definitely makes things look nicer, and removes the need to carry a type around. Also, this means I don't have to mutex around it.
2. I'm still not super happy with all participants having to agree on the type of the data that is being stored – but right now I don't have a better proposal.
3. As long as applications are on their own with the types anyway, I'm be tempted to expose raw access through .lock(). This would almost enable writing a global storage access handler, except that a) there's no enumeration (should be easy) and b) as long as it's postcard we'd need to expose the schemas as well (which brings us to 2 -- CBOR solves this to the extent that a user can GET data, show it, and PUT modified data back, but they will still not know which precise rules apply, and a schema unaware handler won't enforce it).

But for now (and more so once I've figured out how minicbor works with serde), at least it's reasonably easy to expose concrete configurations with concrete types at concrete resources, if we include the CborStorageAccess handler. The reason I'm not proposing that yet is that it includes an unholy hack of bridging the blocking and the async world by running the storage futures on a runner that bails if things are not done by the count of one. That'll be fixed with the WIP iteration of coap-handler