Optimize logbook SQL query

[amelchio]

Description:

The logbook will load a lot of events that it ends up discarding. This change moves some of that filtering to SQL and thus avoids a lot of useless Python objects to be created.

The performance impact depends on the database content but my production setup has about a 50% improvement in logbook loading time (on top of #12566). Nevertheless, the logbook is still very slow :-/

The potential speedup depends on #12580.

Related issue (if applicable): fixes #12572

Checklist:

• The code change is tested and works locally.

If the code does not interact with devices:

• Local tests with tox run successfully.
• Tests have been added to verify that the new code works.

[JudgeDreddKLC]

I've been very lazy about getting the correct environment set up to help with the DB, that's going to change. In the meantime, @amelchio, I'm assuming you already have the correct enviro set up to test changes, would you be bale to add indexes on states.entity_id and states_last_changed and see how that affects performance. If not, no worries, I'm going to start setting stuff up on my end tonight and hopefully will have a dev environment ready this week. I see a lot of room for improvement and I think we can piggy back on the vast improvements made by @OverloadUT a few months back. I'm new to github and formal development infrastructure, so perhaps there's already an easy way for the HASS db folk to communicate, if so, please share.

[OverloadUT]

@JudgeDreddKLC: You should start a discussion in a separate GHI to discuss this, as this is a Merged PR.

My only feedback about that idea is that the logbook does not use the states table, so adding that index will not help logbook issues. (I am very confident that the current states indexes are configured ideally for all current state table queries, but please do challenge this if you find anything specific.)