gcoap: confirmable messaging plan

[kb2ma]

I created a wiki page that describes how gcoap will handle messaging scenarios for the confirmable type. I intend to implement these features incrementally, in digestible commits. See below for the implementation plan, and of course I'm happy to hear any feedback or suggestions.

• Implement server confirmable response piggybacked on the ACK -- server side of scenario (1). Simple and useful, so do this first. (net/gcoap: Provide piggybacked ACK response to confirmable request #7223)

• Create the infrastructure, and refactor the existing messaging to use it. (net/gcoap: Create confirm request infrastructure and adapt existing messaging #7336) This work includes:

  a. Revise gcoap_request_memo_t and add gcoap_resend_t. The hdr_buf attribute, for a non-confirmable type, now will be accessed within the union.

  b. Update CLI example shell command with an option to send confirmably.

• Implement confirmable request with the response piggybacked on the ACK -- client side of scenario (1) on the wiki page. (net/gcoap: Confirmable request with piggybacked ACK response #7337) This includes addition of the resend_bufs array. Also include documentation on how to send a confirmable request.

• Implement confirmable Observe notifications -- scenario (5). (net/gcoap: Confirmable Observe notifications #7548)

• Implement synchronous messaging as described in scenario (1).

• Implement confirmable messaging with separate responses -- scenario (2).

[chrysn]

A few issues/PR have accumulated that should have been created as sub-tasks in here:

• Gcoap does not handle separate responses #14169 (Gcoap does not accept separate responses): ready to be reviewed at gcoap: Process CON responses #14178

  This is an important part of a full CoAP implementations because servers may at any time start responding separately.

• Gcoap can not send separate responses #14393 (Gcoap does not send separate responses): PR draft at gcoap: Send separate response #14395

  This is far less urgent as the Gcoap server may just decide never to do this; relevant though for cases of resources whose representation is not available immediately (on a retransmission timer time scale; anything <0.1s is perfectly fine, and 1s just so is).

The wiki page grew a bit outdated over time (eg. w/rt gcoap_req_send2), I'd like to overhaul it but will need to work a bit more through what has been done already to be sure to capture all of it.

[maribu]

ping?