Add additional parameter to COAP handler functions

[pekkanikander]

Adds a new additional void * parameter to the handler functions. This makes it easier to write handlers functions that handle multiple URLs, e.g. a single function is enough to read multiple I/O pins.

[kaspar030]

@pekkanikander Would "prefix handlers", whose path ends in '/' and which handle a whole subtree, serve your needs?

[pekkanikander]

Prefix handlers would probably cover a part of the use cases that can be handled with the mechanism I implemented. A lot depends on what parameters such a prefix handler would get. But in any case, such prefix handlers would be a very welcome addition. Especially if the handler search algorithm is changed so that you can first have a few special case handlers and then a prefix-handler as a default.

[pekkanikander]

Never mind this comment below. It looks like I'm finding a better solution to the observe problem.

@kaspar030 I am now implementing also observe functionality, using gcoap. It would again be beneficial to extend coap_resource_t, to contain not only the handler but also an observe "handler," i.e. a function that may be called to construct and send an observe notification.

Given this, I started to contemplate that maybe the coap_resource_t type should be made "inheritable." As the resources are compiled into a table, such "inheritance" is not exactly trivial in C....

An alternative would be to extend the coap_handler_t signature to also take a function pointer as an additional parameter. That new function pointer parameter would have the same signature as coap_reply_simple. When the handler is called from a request context, it would be passed the coap_reply_simple. When called from an observe notification context, it would be passed a new function, coap_notification_simple. Of course, the handler could ignore that function pointer.

Or the coap_handler_t could be passed an enum that tells it whether it should construct a reply, a notification, or perhaps something else. That enum could be extended. But so could also the above function pointer. But such an enum would leave more freedom for the handler writer.

[pekkanikander]

Given the experience so far, this way of adding a void * parameter to coap_handler_t does not make that much sense. It is better to add a const coap_resource_t * parameter to the coap_handler_t. That will be a much less intrusive change. I will implement that next. If that works, I will then make another pull request and close this one. This can then work as an archive of the discussion.

[pekkanikander]

Closing in favour of #15.