nanocoap: add coap_iterate_uri_query()

[benpicco]

Contribution description

This adds a convenience function to iterate over a packets's URI query options. Options have the format key=value, but options that only consist of a key may also exist. For consistency, in this case the value is set to "1".

Testing procedure

I extended the tests-nanocoap unit test with the new function.

Issues/PRs references

[benpicco]

Expecting the user to iterate coap_opt_get_opaque() for this is not very user friendly. While I like the idea of querying the desired key directly, it would involve iterating the packet multiple times if we are interested in multiple keys.

With this we can just call coap_iterate_uri_query() in a loop and check all they keys that fall out.

[Teufelchen1]

Slightly off-topic:

Feels a bit odd that riot has a "uri parser" module but this PR adds a function with "uri" and "query" in its name that is not in that module nor does it use functions of that module. Don't get me wrong, I think this PR is fine in this regard - Just makes me wonder a bit.

[chrysn]

On Tue, Dec 19, 2023 at 06:51:43AM -0800, benpicco wrote:

While I like the idea of querying the desired key directly, it would involve iterating the packet multiple times if we are interested in multiple keys.

We're talking about, typically, 3-5 checks that on 1-3 options in a message, which are already in parsed form for iteration. Does that make that much of a difference, especially when it saves you the cost of copying out all the options all the time?

[chrysn]

Slightly off-topic:

The long answer to this is in https://github.com/RIOT-OS/RIOT/issues/13827, which could be a good base for a consistent interface for URIs and locations both on clients and servers, as well as references -- but that's still waiting for the spec to stabilize.

[benpicco]

We'd still have to copy the value with coap_get_uri_query(coap_pkt_t *pkt, const char *key, char *value, size_t value_len_max);, but just that - maybe that's more ergonomic indeed :thinking:

(I don't want a separate function for very possible type of value, as value is always a string the function should return a string)

[Teufelchen1]

Could you add two tests for the cases of returning -E2BIG?

In general, the unit tests lack in quality but a refactor is out of scope for this PR.

[benpicco]

I think even with #20273 this PR is still useful. While coap_find_uri_query() is convenient when you only expect a very limited number of URI query options, it gets unwieldy quickly if your API allows for many option keys so instead of iterating all possible keys, you'd only iterate the keys present with coap_iterate_uri_query().

[Teufelchen1]

Squash'n rebase?