net/gcoap: Provide piggybacked ACK response to confirmable request

[kb2ma]

Implements the first task of #7192 for confirmable messaging. Also updated documentation and added a couple of unit tests.

[smlng]

you could use a switch-case over the possible coap types here, something like

switch(coap_get_type(&pdu)) {
case COAP_TYPE_NON:
case COAP_TYPE_CON:
    size_t pdu_len = _handle_req(&pdu, buf, sizeof(buf), &remote);
    if (pdu_len > 0) {
        sock_udp_send(sock, buf, pdu_len, &remote);
    }
    break;
case COAP_TYPE_RST:
case COAP_TYPE_ACK:
    DEBUG("gcoap: RST and ACK handler not implemented yet!\n");
    break;
default:
    DEBUG("gcoap: illegal request type: %u\n", coap_get_type(&pdu));
    return;
}

[edit] fixed indention above

[kb2ma]

@smlng, thanks for the quick review! I appreciate your debug output to indicate a message can't be handled yet. It made me realize that it wasn't right to say an empty message (code 0.00) is 'illegal'. So, I called that scenario out first, which means that a request code class message must be either NON or CON type. For reference see Table 1 at the end of sec. 4.3 in the spec.

[miri64]

@kb2ma what about the switch-case proposed by @smlng? Other than that: tested on native, samr21-xpro and iotlab-m3.

[kb2ma]

@smlng's code is within the handling for a request-class code (GET, POST, etc). Since RST and ACK types are not valid for a request-class code, there are only two cases -- NON/CON and illegal. A case statement seemed like overkill for only two cases. Am I missing something?

[miri64]

True. @smlng, do you agree?

[smlng]

yes, agreed - RFCs allows NON and CON as requests only. And at least with the current handling of CoAP message types, an if-else is fine.

[smlng]

ACK!

[aabadie]

Let's go here.