net/nanocoap: Buffer API Block implementation

[kb2ma]

Contribution description

Presently, the nanocoap Buffer API includes server side implementation of Block options. In other words, it includes block2 descriptive use (sends blockwise content) and block1 control use (receives/acks blockwise content). This PR extends the API to include block2 control use and block1 descriptive use for client side requests.

At the same time, this PR standardizes block function names to include "control" for control use, as shown in the table below.

Old Function	New Function	Notes
coap_opt_put_block2()	coap_opt_put_block2()	no change
N/A	coap_opt_put_block2_control()	new
coap_put_option_block1() coap_put_block1_ok()	coap_opt_put_block1_control()	coap_put_block1_ok() is a convenience function to only call coap_put_option_block1() if the more attribute is 1. This approach is in error; see below.
N/A	coap_opt_put_block1()	accepts a slicer struct, like coap_opt_put_block2()

Testing procedure

For this PR our main focus is refactoring the current implementation, so testing is for regression. Ensure the nanocoap_server example /sha256 and /riot/ver resources still work.

FWIW, I have functional tests in the riot-coap-pytest repository. If you run block1_client.py, which is a script for aiocoap to POST /sha256, you will see that the old implementation generates the warning below. This is due to coap_put_block1_ok() omitting the block option in the last ACK, as described in the table above. RFC 7959, sec. 3.2 also shows that the final response is expected to include the option in the final ACK.

$ ./block1_client.py -r[${TAP_LLADDR_SUT}] -b 32
WARNING:coap.blockwise-requester:Block1 option completely ignored by server, assuming it knows what it is doing.
Result: 2.04 Changed
b'C496DF5946783990BEC5EFDC2999530EEB9175B83094BAE66170FF2431FC896E'

However, the new implementation does not generate the warning.

$ ./block1_client.py -r[${TAP_LLADDR_SUT}] -b 32
Result: 2.04 Changed
b'C496DF5946783990BEC5EFDC2999530EEB9175B83094BAE66170FF2431FC896E'

The next PR in the sequence includes a couple of helper functions to make the new client side functions easy to use. We will add tests for those uses with that PR, but you can get a preview in the nano-block-client app.

Issues/PRs references

Partially implements #10732. Depends on #10876.

[kb2ma]

Now that #10876 has been merged, I will rebase here.

[kb2ma]

Rebased.

[kb2ma]

Rebased

[fjmolinas]

Tested the nanocoap_server example, /riot/ver is working just as before. But with /shah I'm not getting the shah as a reply:

on master:

→ coap-client -m post coap://[2001:db8::7b7c:91a:4eaa:52de]/sha256 -f examples/nanocoap_server/README.md -b 64
93C814D956114A7FCF4C53580F3D5501AA04C0961C5C035C80C65AECBAE089DF

with this pr:

  ~/workspace/RIOT  |pr-11002 {119} ✓|
→ coap-client -m post coap://[2001:db8::7b7c:91a:4eaa:52de]/sha256 -f examples/nanocoap_server/README.md -b 64
  ~/workspace/RIOT  |pr-11002 {119} ✓|

[fjmolinas]

Tested the nanocoap_server example, /riot/ver is working just as before. But with /shah I'm not getting the shah as a reply:

I replicated the test using nano-block-client and I get the shah, but no payload is sent. I also get the shah when no payload is sent with coap-client:

coap-client -m post coap://[2001:db8::7b7c:91a:4eaa:52de]/sha256 -f examples/nanocoap_server/README.mda
cmdline_input_from_file: fopen: No such file or directory
E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855

[kb2ma]

I can recreate your results with the lastest libcoap master branch as client. However, it looks to me that the difference in the results is solely a feature of libcoap's text output. The sha256 output is included in the payload of the final ACK from the code in this PR's branch. The only difference in the final ACK is the addition of the block1 option. This addition is explained above in the description.

I think the change in the final ACK is the right thing to do, but I will take another look to confirm.

[kb2ma]

I am convinced that the fix to add the block1 option on the final response is correct. I also created obgm/libcoap#383 to output the response in this case.

[fjmolinas]

I tested that there was no regression and although I had some unexpected output when testing with libcoap, it seems to be a problem with the upstream library and not the refactoring done with this PR. ACK

[kb2ma]

Thanks, @fjmolinas! I'll wait a day before merging to give anyone else a chance to speak up.