Ignored handler response msg code

[kamil-lazowski]

I have observed that response message type set by handler is ignored and treated as CON.
To reproduce this issue:

1. Send request with msg.type = CON
2. Handler is not able to answer, return POSTPONE
3. On next call handler is able to answer, configure response msg.type as NON
4. Response is sent as CON

In other words:

Expected:
client CON -> server
server ACK -> client
server NON-> client

Actual:
client CON -> server
server ACK -> client
server CON -> client
client ACK -> server

According to RFC 7252 :

5.2.2. Separate
(...)
When the server finally has obtained the resource representation, it
sends the response. When it is desired that this message is not
lost, it is sent as a Confirmable message from the server to the
client and answered by the client with an Acknowledgement, echoing
the new Message ID chosen by the server. (It may also be sent as a
Non-confirmable message; see Section 5.2.3.)

So application should be able to configure whether the response is CON or NON. I have digged into the lobaro coap lib and found out, that if request was CON and ACK has been sent, response is ALWAYS sent as CON (even if handler has changed it to the NON).
Code responsible for that:

//Set response TYPE correctly if CON request, regardless of what the handler did to this resp msg field, it can't know it better :-)
//on NON requests the handler can decide if use CON or NON in response (default is also using NON in response)
if (pIA->pReqMsg->Type == CON) {
	if (pIA->ReqConfirmState ==
			ACK_SEND) { //separate empty ACK has been sent before (piggyback-ack no more possible)
		pIA->pRespMsg->Type = CON;
		pIA->pRespMsg->MessageID = CoAP_GetNextMid(); //we must use/generate a new messageID;
	} else
		pIA->pRespMsg->Type = ACK; //"piggybacked ack"
}

So current implementation is not consistent with the RFC 7252.
I understand that it was done intentionally, but I believe that it is a bug,