Sort out where AttributeAccessInterface-backed attributes do sanity checks on the (endpoint, cluster) pair

[bzbarsky-apple]

Problem

Attributes handled via the attribute store automatically handle invalid endpoint or cluster ids (i.e. nonexistent endpoint, or cluster not on endpoint), because the attribute descriptor is just not found.

But for things backed via AttributeAccessInterface this is not handed right now. As a result, for example, I can try to read the General Diagnostics cluster on endpoint 200 of chip-all-clusters-app, and that will happily succeed.

Proposed Solution

We need to add checks for the endpoint and cluster being valid. Plausible places to put these checks:

1. Inside the ReadHandler.
2. Inside the Reporting.cpp machinery.
3. Inside ReadSingleClusterData.
4. Inside findAttributeAccessOverride.
5. Inside the AttributeAccessInterface implementations.

My preference there would be "definitely not (5)". There's a case to be made for (4), since that's the place where we are asking "is there an attribute access override for this cluster+endpoint pair?". The tradeoff seems to be that if we put the check inside (4) then we will find we don't match, return no access override, fall into the normal attribute store, discover we don't match again, and return error, which does the "do we match?" work twice. Same thing if we put it inside (1) or (2), actually: there we would end up doing the matching work twice for attributes that are not backed by an AttributeAccessInterface and do exist.

So I think I would go with (3), and in particular just do the check when we find a matching AttributeAccessInterface.

Thoughts?

Related question: should we be guaranteeing, by the time AttributeAccessInterface is called, that the given attribute exists on the given (endpoint, cluster) pair? Or leaving that up to the AttributeAccessInterface to enforce? Seems to me like it would be better to do the former, since then we can easily have a single source of truth (our topology) enforcing it for all attributes.

@erjiaqing @mrjerryjohns @vivien-apple @carol-apple @msandstedt @yufengwangca