gcoap: add lazy init mode

[pokgak]

Contribution description

This PR introduces lazy init mode for gcoap. lazy init mode is for applications that want to first do something before gcoap starts its server thread (e.g. loading credential into credman for (D)TLS). It can be enabled by adding USEMODULE += gcoap_lazy_init to the application Makefile

An alternative to this approach would be to just take gcoap_init() out of autoinit and calls it manually from the application but this may break existing applications, so I prefer not to do that if there is an alternative.

How it works

In lazy init mode, the call to gcoap_init() only initializes the _coap_state but does not start the coap server thread. It will be started at the first gcoap_register_listener() call if there is no server that is started already.

As long as there is no server running, NON requests can be sent as usual but the responses will be ignored. Sending a CON request, on the other hand, will fail because a CON request expects to receive a response. After the server is started (gcoap_register_listener() is called), the application should behave like a normal gcoap application.

Testing procedure

For now, I only tested sending NON and CON requests from a lazy init client to a gcoap normal server.

Set BUILD_IN_DOCKER=0 if you are using Docker to build because the env values are not carried into the container for building.

0. From RIOT base directory: cd examples/gcoap
1. Start a normal gcoap instance: PORT=tap0 make all term
2. Start a gcoap in lazy init mode: PORT=tap1 USEMODULE=gcoap_lazy_init make all term
3. Send a NON from lazy init instance to the normal: coap put <server ip> 5683 /cli/stats 100
4. Check the output of coap info on the server, cli stats must be 100 now
5. Send a CON from lazy init instance to the normal: coap put -c <server ip> 5683 /cli/stats 200
6. Step 5. should fail and the value of /cli/stats at the server should stay 100.

Issues/PRs references

This is part of the work needed to add DTLS support to gcoap. See #12104 (comment).

[pokgak]

@kb2ma this is based on your idea at the last summit.
@leandrolanzieri @smlng might be interested in this.

I hope to get feedback on this and if I could proceed with it :)

[kb2ma]

Thanks for adding me as a reviewer. I plan to look at this after feedback on #11036, hopefully within a week. FWIW, I've been in contact with @pokgak offine. ;-)

[leandrolanzieri]

Some initial comments

[leandrolanzieri]

If a node is not registering additional resources (I know, maybe not the most common of cases), and acts only as a client, then it won't be able to perform CON requests right?

[pokgak]

Yup. This is checked in gcoap_req_send(), if a CON request is made, it will fail to send:

RIOT/sys/net/application_layer/gcoap/gcoap.c

Lines 760 to 765 in 49d1b9e

	#ifdef MODULE_GCOAP_LAZY_INIT
	if (msg_type == COAP_TYPE_CON && _pid == KERNEL_PID_UNDEF) {
	DEBUG("gcoap: cannot send CON request in lazy init mode\n");
	return 0;
	}
	#endif

[leandrolanzieri]

Yes, I saw that. Is that a wanted behaviour?: Every node must register at least one listener to be able to send CON requests.

[leandrolanzieri]

Maybe we could find another way to trigger the server to start

[pokgak]

Alternatively, instead of returning an error, the server can be started from gcoap_req_send() when the client wants to send a CON request. The main goal of lazy init is the delayed start of the server until it is really needed. So starting the server from gcoap_req_send() still fits in the requirement.

[tcschmidt]

O.k. @leandrolanzieri ?

[kb2ma]

Thanks @pokgak for taking a stab at implementation. It's pretty clear this idea was not my best. :-/ The amount of code and the issues raised show it would be simpler to be more explicit about startup.

I just published an alternative PR, #12798 to accomplish this goal. An application can explicitly start gcoap, but by default it still starts at auto-init time.

[pokgak]

Closed in favor of #12798.