Transport versions are mixed up

[nik9000]

Description

Here's main:

    public static final TransportVersion ESQL_REPORT_ORIGINAL_TYPES_BACKPORT_8_19 = def(8_841_0_22);
    public static final TransportVersion INTRODUCE_FAILURES_LIFECYCLE_BACKPORT_8_19 = def(8_841_0_23);
    public static final TransportVersion V_9_0_0 = def(9_000_0_09);

Here's 8.19:

    public static final TransportVersion ESQL_REPORT_ORIGINAL_TYPES_BACKPORT_8_19 = def(8_841_0_22);
    public static final TransportVersion PINNED_RETRIEVER_8_19 = def(8_841_0_23);
    public static final TransportVersion ESQL_AGGREGATE_METRIC_DOUBLE_BLOCK_8_19 = def(8_841_0_24);

These aren't compatible with one another and main can't rolling upgrade from 8.19 at the moment.

[nik9000]

@limotova, @mridula-s109, and @gmarouli , there's been a transport version mixup. I'll try to resolve it, but I'm not sure I'll manage tonight.

Here's what happened, so far as I can tell.

• Failure store lifecycle - claim backport transport version #127633 claimed a transport version from the 8.19 lineage in main.
• [8.19] Pinned retriever (#126401) #127639 claimed the same version in the 8.19 lineage, this time in the 8.19 branch.
• [8.19] [ES|QL] Introduce AggregateMetricDoubleBlock (#127299) #127623 claimed the next version in the 8.19 lineage in the 8.19 branch

Elasticsearch main can't form a cluster with 8.19 because it thinks the changes associated with 127633 are back - but they are not. Instead 127639 and 127623 are.

I'm going to try and brain main into compatibility with 8.19 by modifying main only because I think that'll be less work. To do that, I'm taking the number claimed by 127633 and giving it to 127639. Then I'm adding support to main for 127623.