Stop sending RunState requests if unsupported

[Sammy1Am]

Some hardware doesn't support the RunState (0x09) packet request. This change adds a discovery_mode that will send requests for RunState for the first 5 updates, but then cease if no responses have been received.

This should resolve #23 .

The new discovery_mode will likely come in handy as we attempt to handle capability detection (#13), or other functions that need to take place only during startup but aren't needed once things have settled (installer functions likely included).

[KazWolfe]

As much as I hate saying this, we may want to tweak how we do this overall as part of more intelligently grabbing information from the unit (e.g. checking different packets on a cadence).

It might be worth doing this such that instead of using a raw discovery counter, we just track num_loops_ as a (wrapping) uint or similar. Anything below 5 is considered "in discovery" (rather than having a new field), and then we can spread out requests through modulo of the loops. I've already done this on the old repo, so I'm rather partial to this solution :).

My main concern here is that we might start to see units that don't support error mode checking and the like. We may need to also consider the case of hiding e.g. the filter reset button if run packets aren't discovered, but that will also incur boot delays (?) while we wait for the system to probe.

[Sammy1Am]

We may need to also consider the case of hiding e.g. the filter reset button if run packets aren't discovered

I hope we can figure out how to do that; I'm still not even 100% sure it's possible. It looks like it may be possible to add climate traits after startup, so we might be able to just startup supporting nothing and add things as we do discovery. But I haven't yet seen a way to dynamically add components after boot.

I initially I did just have an update counter, but decided to move to a discovery field because:

• There may be different ways Discovery is completed. For RunState, for example, if we get back a response we can exit Discovery after a single loop. There might be other processes that aren't as update-count dependent (I don't know how the probing process will work yet) that require us to wait more or less time.
• Any auto-config process will probably(?) take place before ESPHome is fully initialized, which means update() might not be called yet. I guess eventually update will get called, but potentially Discovery could be finished by the time we get there (in which case I guess we don't need any discovery field🤷‍♂️).
• At least for checking to see if we're currently In Discovery or not, I (subjectively) prefer just checking a bool instead of having to do a counter comparison each time (especially if at some point the criteria for exiting Discovery change or get more complicated). (Just my opinion, so not like a real reason to stay with it, just explaining my thought process)

then we can spread out requests through modulo of the loops

I still haven't really seen a use-case for this. So far everything seems to be important only at specific times (like startup for capabilities, or when setting for installer functions), or worth getting every update cycle (even error codes I would argue should be checked often in case it's a short-lasting code that clears itself but may indicate coming problems).

We're waiting for responses to be received before sending the next packet, and have a limit on the send queue, so there shouldn't be any issues with overcrowding the wire. The MHK is pretty much constantly asking for info, so it also doesn't seem like Mitsubishi was concerned with adding in quiet time (not that Mitsubishi doing something is really a good reason to copy though 😉).

All that said, I do think things will likely change here a bit as more discovery/probing operations are implemented.