Revert optimized logbook SQL

[amelchio]

Description:

This reverts #12608. It was reported that this SQL can now go into an expensive loop.

The malfunction seems to depend on the stored data or maybe the MySQL version. I propose to remove the optimization until we know for sure.

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.

[juan11perez]

In my case the modification of 12608 had dramatically improved the logbook issue. After months of being unusable it was now loading in less than a minute without depleting RAM. I have updated to 64.2 and after hitting logbook it didn’t load it and yet somehow absorbed 3 GiG of RAM.

[amelchio]

@juan11perez Thanks for the valuable feedback. Databases will act differently depending on the data inside them so testing with all possible configurations is impossible.

The optimization has been re-added in #12881 so it should be in 0.65 (if no other issues turn up).

[juan11perez]

@amelchio thank you for continuously improving this fantastic application. Users like me, with limited knowledge, sometimes underestimate the effort that goes into solving each of these issues and for that I apologise.

I wanted to comment, because I have silently monitored this issue for months and when it was fixed I could notice the difference.

thank you again.