Rework OnOff output cluster handler logic

[elupus]

Currently there is a special logic at

zha/zha/application/discovery.py

Line 449 in 9fe8345

def handle_on_off_output_cluster_exception(self, endpoint: Endpoint) -> None:

that converts a OnOff output (client) cluster into a virtual server cluster through a handler. It will generate attribute updates based on the commands generated by the client cluster.

I assume this logic stems from before we had event entities in home assistant and was some type of attempt to create a binary_input like entity from an OnOff client cluster.

We should add support for event entities for output clusters, and drop this rather confusing special logic for OnOff clusters.

[puddly]

Any sort of virtual clusters need to go, in my opinion. They were created to re-use the existing cluster handlers to create entities. With the ZHA library allowing direct entity creation, we need to start replacing virtual clusters with those.

[elupus]

In this case it's not virtual clusters, it's a virtual entity linked to a handler. The clusters are real here.

[elupus]

The attributes on the cluster is virtual thou.

[TheJulianJES]

It doesn't make sense to convert a binary sensor for open/close or motion/no_motion to an event entity IMO.

The logic regarding OnOff entity discovery needs to be improved, but we should not use event entities in this case.
The OnOff case is only special, as it's an output cluster and we're somewhat misusing the cluster handler.

Other than that, it's similar to IasZone. Both the OnOff (output) cluster and the IasZone (input) cluster only send commands and we convert them to "attribute reports" locally. We can't actually set up attribute reporting for OnOff nor IasZone.

We should, however, consider implementing event entities for remotes with device automation triggers provided by quirks.
And we should make sure the OnOff entity is not displayed for remotes, but only for door/window, motion sensors, and so on. That's a separate issue though: #289