Finish MQTT event handling rework

[dvx76]

In #407 and skodaconnect/homeassistant-myskoda#737 we started reworking how MQTT events are handled, but only did it for charging events:

• MySkoda now owns the callback subscriptions and 'intercepts' the events so it can perform processing before proxying the events to the subscribed callbacks
• Refresh API responses as required + update cached Vehicle with data from Event. All within MySkoda itself
• Client (coordinator in integration) upon receiving a charging event just needs to refresh the Vehicle using MySkoda.vehicle()

The same approach can be implemented for all other events.

Most likely requires implementing a debounce mechanism within MySkoda for querying the API endpoints since events all access events can happen quickly. Actually having a debounce on handling the event itself might be even better. This could also deduplicate the events being proxied back to the MySkoda client...

Also from skodaconnect/homeassistant-myskoda#737 (comment)

We design a place for the client to know about what actually happened inside MySkoda while it was doing this unannounced update. Did we hit an API limit? Did the Internet connection break? Or was all fine. I don't think this is in this PR-set, but could be a follow-up.

[WebSpider]

Moving event handling out of myskoda.py makes sense at this point.

[dvx76]

List of things we want to consider / fix before closing this:

• Move event handling out of myskoda.py
• Debounce event handling itself instead of or in addition to debouncing the resulting API queries. E.g. when receiving 2 change-access/change-lights events within X seconds.
• And/or deduplicate events proxied through to the MySkoda callbacks (probably less relevant now that the coordinator no longer really does anything with the events, other than dump them as-is into the event/operation entities)

Anything else?

Do you remember this comment, also referenced further up? I don't fully understand what we want to do.

skodaconnect/homeassistant-myskoda#737 (comment)

We design a place for the client to know about what actually happened inside MySkoda while it was doing this unannounced update. Did we hit an API limit? Did the Internet connection break? Or was all fine. I don't think this is in this PR-set, but could be a follow-up.

[dkadioglu]

Hi, I was just wondering what the state of this is? May I ask, when you plan to finish this?
Regardless of this, thank you for all your time and great work!

[dvx76]

Hi, I'm not actively working on this at the moment so don't really have an ETA. However the remaining work is mostly refactoring with some potential stability/performance improvements, but no real functional changes.

[dkadioglu]

Thank you very much for your reply! By "no functional changes" you mean that, if I use the myskoda library in a project and when you finish this in the future, there should be no influence on 3rd party implementations using the myskoda library? I am just at the beginning of thinking about some ideas and would like to get a better understanding of possible implications.

[WebSpider]

Thank you very much for your reply! By "no functional changes" you mean that, if I use the myskoda library in a project and when you finish this in the future, there should be no influence on 3rd party implementations using the myskoda library? I am just at the beginning of thinking about some ideas and would like to get a better understanding of possible implications.

We do not expect any changes to the external API as a result of this rework.