CoAP: add remote and local endpoint data to coap_pkt_t

[fabian18]

Contribution description

This is an alternative attempt to expose local and remote IP addresses and ports to the CoAP request/response handlers. The CoAP PDU now contains pointers to local and remote endpoint data.

Testing procedure

examples/gcoap:

> coap get fe80::4c49:6fff:fe54:5c%6 5683 /.well-known/core
2021-09-09 09:42:24,179 # gcoap_cli: sending msg ID 10865, 23 bytes
2021-09-09 09:42:24,183 # gcoap_remote [fe80::4c49:6fff:fe54:5c%6]:5683
2021-09-09 09:42:24,186 # local [fe80::4c49:6fff:fe54:66]:5683
2021-09-09 09:42:24,190 # gcoap: response Success, code 2.05, 46 bytes
2021-09-09 09:42:24,194 # </cli/stats>;ct=0;rt="count";obs,</riot/board>

> coap get fe80::4c49:6fff:fe54:66%6 5683 /.well-known/core
2021-09-09 09:42:25,593 # gcoap_cli: sending msg ID 35428, 23 bytes
2021-09-09 09:42:25,597 # gcoap_remote [fe80::4c49:6fff:fe54:66%6]:5683
2021-09-09 09:42:25,601 # local [fe80::4c49:6fff:fe54:5c]:5683
2021-09-09 09:42:25,605 # gcoap: response Success, code 2.05, 46 bytes
2021-09-09 09:42:25,609 # </cli/stats>;ct=0;rt="count";obs,</riot/board>

Issues/PRs references

Replaces #16429
Trying to solve #15686

[maribu]

Maybe it makes sense to have a dedicated function for this. This function could assert() that the endpoint indeed of a UDP flavor, once multiple protocols are supported.

[bergzand]

At a first glance this looks similar to #13621. Did things change enough in the mean time to reconsider adding this?

[maribu]

At a first glance this looks similar to #13621. Did things change enough in the mean time to reconsider adding this?

That was closed in favor of another PR that was closed in the meantime. However, the feature was added by exposing the remote addr as an additional argument. The same could be done here, which is what @fabian18 first did - but that is an API change (PR still open).

I take it that you prefer that version?

[miri64]

I think we should at least wait for the outcome of tomorrow's CoAP API breakout session at the summit, before we can conclude on this definitively.

[bergzand]

I take it that you prefer that version?

I'm just passing by and noticed similarities, I haven't looked good enough at all the options to have a good opinion or preference.

[miri64]

(see https://hackmd.io/o_y0nKfGRSqrkg-YTCf97g for some initial notes)

[maribu]

Blocking until breakout session during the summit concludes

[miri64]

Blocking until breakout session during the summit concludes

I think the conclusion was that longterm we move to another API, but short-term we move out the gcoap members out of nanocoap into a new gcoap_pkt_t struct. IMHO, before we worsen things for nanocoap, this should be done first, but I don't hard-NACK the approach of merging this first and cleaning up later.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.