refetching transit leg will not work if an additional call is added into the leg real-time

[miklcct]

Expected behavior

The leg can be refetched

Observed behavior

The refetch leg call returns null

Version of OTP used (exact commit hash or JAR name)

2.7.0-SNAPSHOT

Data sets in use (links to GTFS and OSM PBF files)

Any GTFS feed with replacement trips adding station calls in GTFS-RT update.

Steps to reproduce the problem

1. Get an itinerary with leg IDs
2. Add an extra call into one of the legs by means of a replacement trip in GTFS-RT
3. Refetch the leg.

It returns null because the stop position in pattern has changed, so ScheduledTransitLegReference can't match it.

I think that for post OTP-2.5, it should fall back to using stops (including other platforms in the same station) to refetch the leg if the stop position doesn't match.