[WIP] gcoap: adapt to API change in PR 20900

[maribu]

In PR 20900 promotes access to header fields through helper functions on the C side, in the hope that this will allow similar but not quite UDP transports in addition to UDP (TCP and WebSocket) directly in nanocoap. This adapts and uses a helper to access the header instead.

[edit/chrysn: made PR a link]

[maribu]

@chrysn What would be the idomatic way to do this change backward-compatible? The struct member hdr on the C side will no longer be present in the PR, at least when non-UDP transports are (also) used.

[chrysn]

I'll check, but the riot-wrappers shouldn't expose any of the fields anyway, so they can just switch over to the accessors in a compatible way.

[chrysn]

Looks good already -- is RIOT doing a release transition to provide coap_pkt_set_code and only then break the struct access API, or is this an instant-breaking change in RIOT?

If there is transition, I think we can just do this as-is already, at latest when coap_pkt_set_code is available.

If there is a breaking change without transition release, there'll need to be a marker based on which to infer the right behavior. (I've simplified markers recently because most of it could be done through riotbuild.h in recent times; not sure that's the case here).

[maribu]

If there is transition, I think we can just do this as-is already, at latest when coap_pkt_set_code is available.

Sadly, the helper coap_pkt_set_code() is not yet in RIOT (a getter for the code was already present, though). So just switching to the setter will not build with RIOT until the PR in question is merged.

I could split out a PR to add the setter and backport that to the latest release, hoping on getting a release maintainer approval for a feature backport. But that would still bump the RIOT version requirements of the rust-riot-wrappers.

[chrysn]

With the plan laid out in RIOT-OS/RIOT#20900 (comment), it should be fair to have this PR's change conditional: if any of the new modules are in (say, #[cfg(any(riot_module_gcoap_tcp, riot_module_gcoap_websockets))), the new version is used; otherwise, the old is used. If that's creating too much churn, it might be an option to create a pseudomodule gcoap_nonudp that the new ones depend on, but I don't anticipate that there'll be an inrush of transports right away.

We don't have a dependency on the cfg-if crate in the wrappers, so the old implementation would need to be kept in sync with a #[cfg(not(any(riot_module_gcoap_tcp, …)))] statement; I think that's fine, but if you think it is ugly, cfg-if could be added. (But all this will be out first thing after the next RIOT release anyway).