Migrate Webserver to Flask and Jinja templates.

[jscheidtmann]

... from Bottle.

This PR migrates the internal PiFinder webserver to Flask and Jinja and translates the webserver strings.

• Created selenium tests for all webserver functionality
• Successfully ran selenium test suite against server2 webserver (jinja2 templates)
• have babel extract the newly identified strings
• Translate strings to German
• Translate strings to French
• Bootstrap spanish translation using LLM

This PR introduces a /api/current-selection endpoint that provides information on the currently selected menu entry or ui-element. The selenium tests use this to validate the remote control and change the state of the PiFinder.

Known limitations:

• The language of the webserver does not change when the language in the UI is changed. This is due to the webserver running in it's own process. At the moment, you need to restart the PiFinder service, so that the new language is picked up (while the UI on the PiFinder picks up the change immediately).
• The selenium tests need to have the PiFinder using english language.

[jscheidtmann]

@brickbots @mrosseel This PR is ready for review and then merge.

[brickbots]

Hi @jscheidtmann Thank you for this switch to enable i8n and the great test coverage 🙌 This is a great set of improvements. I have a couple requests and a couple of questions I'll put here and I'll leave a couple of inline notes:

Change Requests:

• I think the Indi POC commit may have snuck into the wrong branch. Would you please remove it in prep for merging this PR?
• In both server and server2 the key codes were switched back to UP/DN/A/B/C/D from PLUS/MINUS/UP/DOWN/LEFT/RIGHT. I can see that this was fixing a bug caused by the template still sending UP/DN/A/B/C/D. To correct this defect I'd rather keep the key codes using PLUS/MINUS/UP/DOWN/LEFT/RIGHT and adjust the templates to match.

Questions:

• Why server2/views2 instead of replacing server/views? Is there a reason to have both available? If not, let's switch over and not duplicate the code/views.
• The UI State serialization adds a lot of code in the menu manager and UI modules. I can see this is useful for testing... but I can't help thinking we can get almost the same testing capabilities with less code. I guess I don't really have a question here... just a note for future tech/debt reduction. I'm going to file an issue to revisit this once the main code is AsyncIO enabled. Once this is done, we can run a server/endpoint specifically for testing from within the main UI code and potentially be a bit more specific about the items we serialize, or re-work the UIBase class to use introspection to do a bit of auto-serialization. 👍

[brickbots]

Thanks again @jscheidtmann! Please let me know if you have any questions or thing I'm off base on any of these comments 🤝

[jscheidtmann]

Hi @brickbots - Richard,

Re: Indi PoC - yes, that sneaked in. I'll remove it.

Re: A/B/C/D vs. LEFT/UP/DOWN/RIGHT and such - I wanted to get the functionality working with the least changes to server.py. I'll change it to the new ones.

Re: views / view2 + server/server2 - I developed a parallel implemention, in order to be able to perform a direct comparison, if necessary (primarily to be able to switch back and check, if it's an old bug or newly introduced). I also wanted to be able to run the tests against the old implementation but then decided it's not worth the effort/to spend tokens. I'll change the PR to remove the old implementation.

Re: lots of code in ui for serialization - I let claude generate the serialization and it was guided by necessities of the web testing. I did not consider general, dynamic or introspection approaches to serialization. The endpoint's primary purpose is the web testing, and I am not sure how a "good" api for that could look like. E.g. it's rather pythonish at the moment and it would be hard to generate a WSDL for that (if WSDL is still used). If python had conditional compilation, I'd argue that this endpoint should only be defined for development environments.

Re: fixtures - Good point. Will do that.

I also saw, I did not remove the dependency on botte. :-D

[brickbots]

Thanks @jscheidtmann!

Yes, I'm also not sure what to do with the UI testing code. It's good to have, and it should not cause much issue at runtime, but it does add to the source file size and probably does impact performance on the main loop at least a little bit. I think we leave it for now to get this all merged and I can circle back when I have some more time to think about it 👍

I've created a ticket so I don't forget: #346

[jscheidtmann]

• Remove Indi PoC
• A/B/C/D -> LEFT/UP/DOWN/RIGHT etc.
• Remove server.py/view and rename server2.py/views2
• Move driver and shared_driver to web_test_utils
• Remove bottle dependency
• Run the tests against an actual unit
• Tune down webserver logging to not swamp the online logs display
• Test with Safari browser on actual unit, if downloads work.