TMF CoAP messages checking for Confirmable/Non-confirmable is too strict

[EskoDijk]

Describe the bug A clear and concise description of what the bug is.

In many places in the Openthread code, checks like below are performed on a received TMF message:

VerifyOrExit(aMessage.IsConfirmablePostRequest());

But in CoAP, the messaging layer (CON/NON) is separated from the request/response processing layer, and therefore the CON or NON transport does not impact the semantics of the request or response. Forcing a particular transport (CON/NON) at the receiver side seems to serve no purpose and also limits the full use of CoAP features in the future.

Please feel free to provide some comments here -- I won't make a PR for this if the basic assumptions are not agreed on, of course.

To Reproduce Information to reproduce the behavior, including:
N/A

Expected behavior A clear and concise description of what you expected to happen.
Only check for required CoAP message elements at the req/resp layer, such as request method (e.g. verify it is POST).

VerifyOrExit(aMessage.IsPostRequest());

Additional context
See RFC 7252

[abtink]

@EskoDijk, I agree, makes sense to me to relax the condition if it's permissible for specific commands.

[jwhui]

Relaxing the constraint makes sense to me.