uplift: add Vue train-selector widget for uplift target selection (bug 2044143)

[cgsheeh]

Add a train-selector widget that progressively enhances the Django-rendered
"Uplift repositories" checkboxes in the uplift request modal. The native
checkboxes remain the source of truth for the form submission, so the backend
is unchanged -- the widget only reads and toggles them, and falls back to the
plain checkboxes if it cannot load.

When the "Request Uplift" button is first clicked, the widget fetches
release-train guidance from the whattrainisitnow.com API (see bug 2045812) and
validates the response with a Zod schema. That response describes the current
state of the release cycle (which version is on each train, whether betas
remain, whether the release candidate has shipped); the held response drives
every recommendation, landing description, and warning the widget produces.

The page CSP's connect-src is widened to the API origin, which a csp_origin
helper derives from the configured URL.

The widget presents two tabs:

• "Select Firefox Version": choosing a target version resolves -- based on the
  current cycle state -- to the correct uplift train(s) (beta, release, or
  both), ticks the matching repositories, and shows a single line describing
  where the patch will land.
• "Select Uplift Train": manual repository selection with per-train landing
  hints that reflect the cycle state, including a warning when beta is selected
  after betas have closed.

The tabs are keyboard- and screen-reader-accessible.

Builds on the Vue/TypeScript frontend bootstrap (bug 2047613).

[github-actions]

View this pull request in Lando to land it once approved.

[cgsheeh]

Screenshots:

API could not retrieve data from whattrainisitnow.com:

[cgsheeh]

Note: the PR has test failures due to being formatted with the changes from #1251. I figured using that formatting would make this easier to review and reduce churn once we merge that PR.

[shtrom]

LGTM (though I'm a bit over my head about Vue 😅).

Blocking for discussion point, but barring those, I have no issue.

[zzzeid]

First pass, did not review the tests thoroughly but can do that on the second pass.

[zzzeid]

This would be better as a single <p> element with the class and content set based on the response result. We could probably simplify this even further by interpreting the response directly, but this would be a step towards that:

<p v-if="loadingMessage" class="help" :class="{'is-info': isLoading, 'is-warning': isErrored>
    {{ loadingMessage }}
</p>

[zzzeid]

This comment is not addressed. I think it would be nice for us to start using a template-centric approach here, so that we shape the payloads (where we can) to simplify the templates, rather than the other way around. This will make it easier to modularize the templates/components.

[cgsheeh]

Added a statusMessage which is a computed() that returns a string for display in a single <p>, or nothing if the widget should be rendered.

[shtrom]

lgtm

[zzzeid]

Meant to add this to a comment as well, but if we add a proxy API endpoint in Lando we can avoid having to modify CSP settings.

[cgsheeh]

I added tracking on the UpliftSubmission model so we can see how often the widget is used once we roll this out. Just wanted to call that out as an extra addition on this iteration.

[shtrom]

lgtm!

[shtrom]

TIL sugar for .update

[zzzeid]

This branch needs to be updated as it's no longer showing only the changes in this branch (merging/rebasing should work). Currently it's showing changes already in main.

[cgsheeh]

This branch needs to be updated as it's no longer showing only the changes in this branch (merging/rebasing should work). Currently it's showing changes already in main.

@zzzeid this is fixed.

[zzzeid]

Meant to add this to a comment as well, but if we add a proxy API endpoint in Lando we can avoid having to modify CSP settings.

@cgsheeh @shtrom any thoughts about this? This will give us more control over the API response shape, error handling, and would simplify the implementation / streamline all client calls to be via Lando instead of third party sites.

Can be done in a follow up, but I think this would be good to consider.

[cgsheeh]

Meant to add this to a comment as well, but if we add a proxy API endpoint in Lando we can avoid having to modify CSP settings.

@cgsheeh @shtrom any thoughts about this? This will give us more control over the API response shape, error handling, and would simplify the implementation / streamline all client calls to be via Lando instead of third party sites.

Can be done in a follow up, but I think this would be good to consider.

I think it depends on which external sites we'll be contacting. For something like whattrainisitnow.com, we can either ping SRE or RelMan for support, so I'm not worried about having to simplify or change the API response shape. Github/Phab have API key and rate limiting considerations, so keeping those going through the Lando backend makes sense to me.

Seems like a reasonable idea but we should approach it on a case-by-case basis as the need arises. 👍