Fix handling of ZCL Default Response

[manup]

This PR adds automatic handling of ZCL Default Response to also catch cases where we currently miss sending the response.

The magic happens by observing outgoing APS requests if they contain a specific ZCL response and automatically send the ZCL Default Response at the end of the APS indication processing. For this C++ RAII is used with an extra ZclDefaultResponder object which sends the response in its destructor.

• All outgoing APS requests use ApsControllerWrapper instead of plain ApsController.
• All manual sending of ZCL Default Responses was removed.
• Moved isSameAddress()into utils.h.
• Removed sendZclDefaultResponse() from plugin.

[Smanar]

Hudge code.

So we already can remove all

        if ((zclFrame.commandId() == XXXX )&& !(zclFrame.frameControl() & deCONZ::ZclFCDisableDefaultResponse))
        {
            sendZclDefaultResponse(ind, zclFrame, deCONZ::ZclSuccessStatus);
        }

?

Or need to check case by case ?

[manup]

So we already can remove all

        if ((zclFrame.commandId() == XXXX )&& !(zclFrame.frameControl() & deCONZ::ZclFCDisableDefaultResponse))
        {
            sendZclDefaultResponse(ind, zclFrame, deCONZ::ZclSuccessStatus);
        }

Yes, in fact the PR removed all of these :)

Or need to check case by case ?

No, basically the PR is made to not worry about ZCL Default Response at all anymore.

[Smanar]

Yes, have see it after ^^.

Real improvement for me, was realy a weakness for me.

[manup]

I hope so. We have seen increasingly problems for missing ZCL Default Reponse and I guess lots of issues are related although the reason wasn't seen to be this problem, with effects like devices dropping off or rejoining etc.

The PR touches lots of files but the actual code is rather minimal.

[SwoopX]

Great stuff. From my perspective, this addresses one of the current major weaknesses and will hopefully automagically solve some issues users are experiencing.

I've let the code run a bit in my test environment and made some observations so far:

• A default response is sent prior to a response (now observed with 2 devices)

• A default response might have taken too long to prevent a resend of the initial command

Especially the latter is a bit hard to judge upon, since the device is not yet supported. Guess APS data could give some clarity.

[manup]

I've let the code run a bit in my test environment and made some observations so far:

* A default response is sent prior to a response (now observed with 2 devices)

Oh I need to double check this, I think the default responder shouldn't handle OTA related commands since the REST plugin is independent of the OTA plugin.