Don't signal MR rebase if on current fast-forward train

What does this MR do and why?

Currently, when the first car of a fast-forward merge train is merged, MRs for subsequent cars on the train are shown as "should be rebased" in the UI.

But this is not necessary, because fast-forward merge trains automatically rebase internally on their merge train ref, and perform a fast-forward merge directly from the train ref. And if the train ref turns out to be out of date, then the merge itself will fail later because the fast-forward condition would be broken.

See #420000 (closed)

Screenshots or screen recordings

Before	After
MR is on train but shows as Merge blocked	MR is on the train with no Merge blocked warnings

How to set up and validate locally

1. Follow the steps in !130763 (merged) to enable the feature flags and set up the project
2. Rapidly add lots of MRs to the train
3. Watch that as the first MR gets merged, subsequent MRs don't get prompted for a rebase

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.