Editor: importing feed normalizes stop_times#stop_sequence values causing mismatch with GTFS-rt

[landonreed]

Observed behavior

Importing a GTFS feed into the RDBMS-backed editor will normalize stop_sequence values so that these are predictable and SQL queries can expect stop_times to start at zero and increment by one.

gtfs-lib/src/main/java/com/conveyal/gtfs/loader/Table.java

Lines 885 to 889 in 130ff68

	* Normalize stop sequences for stop times table so that sequences are all zero-based and increment
	by one. This ensures that sequence values for stop_times and pattern_stops are not initially out
	of sync for feeds imported into the editor.
	NOTE: This happens here instead of as part of post-processing because it's much faster overall to perform

This was originally determined to be a good design decision with no side effects, but since then we have uncovered that modifying the stop_sequences can cause the GTFS static feed to be out of alignment with GTFS-realtime Trip Updates feeds with selectors that target stop_times by stop_id and sequence. This mismatch was first encountered when importing the Pace Bus GTFS file into the editor to update feed_info#feed_id for use with the GTFS-rt feed in an OpenTripPlanner deployment.

Expected behavior

Ideally, this normalize stop sequence operation would not happen at all and we would redesign the system to accommodate stop times with non-zero based, non-incrementing stop_sequence values. Outside of that, there may be a way to only modify the stop_sequences on update and leave the stop_times alone unless they were updated by a pattern.

Steps to reproduce the problem

1. Import Pace Bus feed
2. Load into editor
3. Snapshot and publish feed.
4. Download GTFS and observer stop_times#stop_sequence changes.

Notes on configuration and files required to reproduce the issue

n/a