feat: landscape magic attach

[matthew-hagemann]

WIP: Currently just lifting the Ubuntu Pro pages from init out into bootstrap.

[matthew-hagemann]

@d-loose still a WIP, and haven't removed the extra pages yet, but if you are happy with how the landscape page and model are looking and how I unblocked the tests, I'll close the ticket to move over to riverpod annotations. Thanks again for all the help!

[d-loose]

One thing I forgot to mention: we briefly talked about https://pub.dev/packages/qr_flutter the other day - would be great if you could check whether that's a more future-proof package for QR code generation than the one we're currently using here

[matthew-hagemann]

One thing I forgot to mention: we briefly talked about https://pub.dev/packages/qr_flutter the other day - would be great if you could check whether that's a more future-proof package for QR code generation than the one we're currently using here

Discussed on MM, we found the current library produced (bottom) clearer QR codes, so will not swap libraries.

[d-loose]

Looks really good so far!
One thing I noticed during a quick test with your mock server: if I change my mind and navigate back from the landscape page that shows the QR after entering an fqdn, the listener on the stream returned by watch() is never cancelled, so if a successful response comes back after some time, we still write the autoinstall file and restart the installer. I think that's not supposed to happen, so we should make sure we only listen to the response stream while the user is on that page.

More detailed review comments soon!

[d-loose]

I have a bit of a refactoring proposal (since you've already spent quite a lot of time on this PR, I wouldn't mind merging this and coming back to it later on, though).

Current state management:
There's a single view model (LandscapeDataModel) for both the 'landscape domain' page where attach() is called and the 'landscape' page where watch() is called. The state this model holds includes the domain entered by the user as well as the status response from the server. It also keeps track of a stream/provider subscription and updates its own state whenever a stream event is received (after calling watch()). Listening/cancelling needs to be handled explicitly through corresponding method calls.

Proposed refactor:
We can split this into two view models. The one for the 'landscape domain' page would

• hold the domain entered by the user
• provide an attach() method

Instead of storing the received userCode in the view model, we could simply pass it to the route that displays the 'landscape' page.

The model for the 'landscape' page would then be a stream provider family (i.e. a stream provider that receives the userCode as an argument to its build function) that exposes a stream of UI states for the page. Simply using ref.watch(autoinstallLandscapeProvider(userCode)) would then take care of the stream's lifecycle (i.e. start listening when the user enters the page, cancel when they leave).

-> UDENG-5870