[WSL] Allows conditionally skipping the SelectLanguagePage

[CarlosNihelton]

Setting up WSL results in an Ubuntu environment with locale set to C.UTF-8 by default. So, if a GET request returns anything different from that value it means the server acknowledged some configuration data for the language, such as when the prefill information file is passed via command line. In such scenarios Subiquity configures the locale controller, so clients can skip the language selection page.

This PR leverages that to skip the SelectLanguagePage conditionally. Two consequences unfold:

1. We can no longer assume the selectLanguage to be the default initial route and
2. We no longer need to request the server for the language in the SelectLanguagePage because that's only shown if the server is set to C.UTF-8, for which the parseLocale sets the UI in English.

Those consequences are reflected in the changes herein submitted to the test code.

Skipping that page on the Windows entry point, where it has to pass through the InstallationSlidesPage was a bit more evolving, because the decision of whether the SelectLanguagePage could be skipped or not could only be taken close to the moment when the slides page kicks itself out of the stage. InstallationSlidesModel now requires knowing about the AppModel. Thus the AppModel is now passed via a ValueListenableProvider, which carefully exposes the current value, without exposing the listenable object itself. That combined with the ChangeNotifierProxyProvider allows the view model to be in sync with the AppModel without being able to trigger the listenable object by accident.

[jpnurmi]

Hmm, we should expose the auto-install HTTP headers for our SubiquityClient responses. Those headers would tell whether endpoints are configured.

[CarlosNihelton]

Hmm, we should expose the auto-install HTTP headers for our SubiquityClient responses. Those headers would tell whether endpoints are configured.

I believe this would simplify a lot this use case and many others for the desktop installer in the future.

[jpnurmi]

Should we wrap all return values with SubiquityResponse or something like that? Can you think of a nicer way to expose that information from subiquity_client?

[CarlosNihelton]

Should we wrap all return values with SubiquityResponse or something like that? Can you think of a nicer way to expose that information from subiquity_client?

EIther SubiquityResponse<T> across the board or create new methods for the relevant GET requests that return the wrapped response instead of the value-only. For example:

Future<SubiquityResponse<String>> localeWithStatus() {
...
}

Future<String> locale() {
...
}

The alternative seems to be less intrusive and allows for a smoother transition. After all, not all GET requests will demand inspecting the x-status or x-updated headers. Yet, I'm not in love with any of the options.

[jpnurmi]

LGTM 👍