[REQUEST] Implement stop times time and distance verification for a trip

[maximearmstrong]

Is your feature request related to a problem? Please describe.
Stop times in a trip should be have increasing time and distance. This is a GTFS rule implemented in Google Python validator as ValidateStopTimesSequenceHasIncreasingTimeAndDistance.

Describe the solution you'd like
Actual Google GTFS validator behaviour : verifies the time and distance travelled at a stop time in a trip is greater than the previous ones. (verifies the stop time and the distance travelled according to the shape)
https://github.com/google/transitfeed/blob/d727e97cb66ac2ca2d699a382ea1d449ee26c2a1/transitfeed/trip.py#L595

Describe alternatives you've considered

Additional context
Line 203 in Error support priorities https://docs.google.com/spreadsheets/d/1vqe6wq7ctqk1EhYkgtZ0_TbcQ91vccfs2daSjn20BLE/edit#gid=0

[barbeau]

cc @timMillet

Note that the Python validator allows sequential arrival and departure times in a trip to be the same - so you can have:

1, 12:00:00, 12:00:00
2, 12:10:00, 12:10:00
3, 12:10:00, 12:10:00
4, 12:15:00, 12:15:00

The Python validator only flags times that go backwards in time. This caught us in the GTFS-RT validator, as we initially implemented a rule that said that predictions needed to move forward in time for each stop (see CUTR-at-USF/gtfs-realtime-validator#365).

Allowing sequential times being the same dates back to a major scheduling software package called HASTUS rounding times to the nearest minute:
https://github.com/google/transitfeed/blob/d727e97cb66ac2ca2d699a382ea1d449ee26c2a1/transitfeed/trip.py#L733

I don't know for sure if HASTUS still has this issue, although someone flagged that issue with our GTFS-RT validator, so I assume it (or another GTFS exporter) does.

It would be nice to update the validator to be more strict rules for this if the state of the industry allows. If not, we may have to implement some of the same heuristics in the Python validator:

# HASTUS makes it hard to output GTFS with times to the nearest second
# it rounds times to the nearest minute. Therefore stop_times at the
# same time ending in :00 are fairly common. These times off by no more
# than 30 have not caused a problem. See
# https://github.com/google/transitfeed/issues/193
# Show a warning if times are not rounded to the nearest minute or
# distance is more than max_speed for one minute.

[lionel-nj]

Time travel verification is already implemented:

• check arrival_time < departure_time
  

  gtfs-validator/usecase/src/main/java/org/mobilitydata/gtfsvalidator/usecase/ValidateStopTimeDepartureTimeAfterArrivalTime.java

  Line 31 in 1d5dab8

  public class ValidateStopTimeDepartureTimeAfterArrivalTime {

• check bad combination of arrival_time and departure_time of timepoints:
  

  gtfs-validator/usecase/src/main/java/org/mobilitydata/gtfsvalidator/usecase/ValidateBackwardsTimeTravelForStops.java

  Line 30 in 12d6ff2

  public class ValidateBackwardsTimeTravelForStops {