"Try again" mechanism for snaplist comes with no guarantee that snaps will be installed

When reaching the snaps selection section, some scenarios will cause Subiquity to show the following message:

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
 Featured Server Snaps [ Help ]
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Sorry, loading snaps from the store failed.

                 [ Try again ]
                 [ Continue ]

If the error was caused by something temporary, the list of snaps might load successfully after hitting "Try again". And if it does, the user can then select snaps to install.

The problem is that when subiquity shows this "Try again" window, the server has already marked the snaplist model configured. Therefore, the installation may or may not have already generated the cloud-config configuration by the time the user selects the snaps they want to get installed.

If the cloud-config was already generated, the snaps selected by the user are ignored and do not get installed by cloud-init.

Technical details:
GET /snaplist will mark the snaplist model configured if the result is FAILED.

subiquity/server/controllers/snaplist.py

    async def GET(self, wait: bool = False) -> SnapListResponse:
        if self.loader.failed or not self.app.base_model.network.has_network:
            await self.configured()
            return SnapListResponse(status=SnapCheckState.FAILED)
        if not self.loader.snap_list_fetched and not wait:
            return SnapListResponse(status=SnapCheckState.LOADING)
        await self.loader.get_snap_list_task().wait()
        if self.loader.failed or not self.app.base_model.network.has_network:
            await self.configured()
            return SnapListResponse(status=SnapCheckState.FAILED)
        return SnapListResponse(
            status=SnapCheckState.DONE,
            snaps=self.model.get_snap_list(),
            selections=self.model.selections)

IMO it makes sense to allow the user/client to retry (or at least decide what to do) when this type of error (generally caused by the network) is encountered. If we want to keep a retry mechanism in place, we should not mark the models configured automatically - especially the last one.