net/nanocoap: Buffer API Block helper functions

[kb2ma]

Contribution description

#11002 added client side implementations for Block for the Buffer API. This PR refines the implementation with helper functions.

Function	Description
coap_block2_finish()	Refactored as inline, added coap_block1_finish() as inline for client side, and coap_block_finish() implementation.
coap_block_object_init()	Added for client to init a block2 control request, and refactored coap_opt_put_block() to use it.
coap_block_slicer_init()	Added for client to init a block1 descriptive request, and refactored coap_block2_init() to use it.

You can see the client side functions in action in block_client.c in my RIOT apps repostiory.

Testing procedure

The nano-block-client RIOT app provides a command line with commands to generate CoAP requests for nanocoap_server example resources. So you can verify both client and server side.

• get creates a block2 request for /riot/ver
• post creates a block1 request for /sha256

Issues/PRs references

Partially implements #10732. Depends on #11002.

[benpicco]

needs rebasing.

[kb2ma]

This PR is part of a sequence, as shown in a comment on #10732. The next PR in the sequence is #11002, which was rebased at the beginning of May. I would be happy to work through merging that one, and then move on to this one.

[benpicco]

Ah sorry, I was just trying to figure out why lost Confirmable messages were not send again, so I started looking if there was still something missing in RIOT's CoAP implementation.

[kb2ma]

@benpicco, if you still have concerns about Confirmable retries, please open an issue. I'd be happy to work through it with you.

[benpicco]

Sorry for the confusion, it turned out the problem was entirely unrelated to CoAP.

[kb2ma]

Rebased

[fjmolinas]

@kb2ma with testing I have the same issue than in #11002

[fjmolinas]

@kb2ma with testing I have the same issue than in #11002

Tested server and client side. I only had a problem when using libcoap where the shah didn't get printed. But as in #11002 that is attributed to a problem with libcoap and not this PR.

[fjmolinas]

Here coap_block_object_init receives a bool more but in it declaration its type is int. Shouldn't it be a bool in both cases? Change the documentation accordingly if its the case.

[kb2ma]

Thanks for reading closely. We specifically use coap_opt_put_block() when writing a block, so it's only useful for its more parameter to be a bool. At the same time, coap_block_object_init() directly sets the struct attribute values, and the more attribute can take on a value of -1, so it makes sense for the function to support that. I think this is a case where the declaration of coap_opt_put_block() and coap_block_object_init() make sense as they are, and it's OK to let the definition of bool as 0 or 1 bridge the gap.

However, the doc comment for coap_block_object_init() only explicitly refers to use of 0 if we don't know if there are more blocks. I will extend the comment to be more precise about use of 1 and 0. However, I'd like to leave the use of -1 as unspecified because we don't expect anyone to use it for this purpose. That may change in the future, and if it does we won't need to change the API to accommodate it.

[fjmolinas]

OK!

[fjmolinas]

I only have one comment regarding documentation, see above.

[fjmolinas]

@kb2ma This looks good to me, I would say squash directly unless you want to wait for someone else to take a look. But ACK on my side.

[fjmolinas]

Also please trigger the ci build once squashed.