refactor(StopPageRedesign): use route patterns

[thecristen]

Summary of changes

Asana Ticket: Stops showing Headsign for Route Even if One Direction of Travel

Backend highlights

• Adds /api/stop/:stop_id/route-patterns to get a JSON object of augmented route patterns grouped by headsign and route ID.
• Replaces the /routes/by-stop/:stop_id with /routes/:route_ids that returns a JSON response containing a simple list of routes.
• The polyline information continues to be computed in the backend, but is now part of the route pattern response as opposed to appending the routes response.

Frontend highlights

• Adds a loader to the React Router's configuration to fetch the route patterns, which will be available from within child components via React Router's useLoaderData() hook. Disables revalidation because this data is not going to change.
• Adds a helper function, departureInfoInRoutePatterns, to filter the list of departures against a list of route patterns.
• Lots of restructuring:
  • <StopPageRedesign />
    • Get route patterns, and use the route IDs from that to fetch routes
    • Don't wait for routes to return a defined response, since they never will for stops that don't have any route patterns (South Attleboro)
  • <DeparturesAndMap />
    • Remove no longer needed routesWithPolylines prop
    • Get route patterns, use the included polylines
  • <StopPageDepartures />
    • Get route patterns, figure out route patterns for the filtered routes
  • <DepartureCard />
    • Add routePatternsByHeadsign prop
    • Refactors to render a <DepartureTimes /> per each headsign
    • Sets an onClick variable to pass to child
  • <DepartureTimes />
    • Adds headsign, isCR, and onClick props
    • Removes check of stop name against route's direction_destination as it should no longer be needed. Removes no longer needed route, directionId and stopName props.
    • Renames departuresForDirection prop to just departures (they were filtered by departureInfoInRoutePatterns earlier)

---

General checks

• Are the changes organized into self-contained commits with descriptive and well-formatted commit messages? This is a good practice that can facilitate easier reviews.
• Testing. Do the changes include relevant passing updates to tests? This includes updating screenshots. Preferably tests are run locally to verify that there are no test failures created by these changes, before opening a PR.
• Tech debt. Have you checked for tech debt you can address in the area you're working in? This can be a good time to address small issues, or create Asana tickets for larger issues.

New endpoints, or non-trivial changes to current endpoints

• Have we load-tested any new pages or internal API endpoints that will receive significant traffic? See load testing docs
• If this change involves routes, does it work correctly with pertinent "unusual" routes such as the combined Green Line, Silver Line, Foxboro commuter rail, and single-direction bus routes like the 170?

[i0sea]

I believe there was a check for "is at last stop" on the JS side. Has that been removed since it's happening here?

[thecristen]

@i0sea Yep, it's been removed!

[i0sea]

nitpick: rename to get_by_route_ids for clarity

[thecristen]

@i0sea okay, changed

[i0sea]

Not sure if this was occuring before these changes but am noticing routes that never stop at a given stop being listed with a headsign -> no upcoming trips. Example the 32 never stops here but is listed anyway. The oneway headsigns do appear to be dropped

[i0sea]

Edit: noticing above issue on dev green as well so unrelated to these changes 🚀

[thecristen]

@i0sea good looking out -- looks like the 32 does stop there, but under one of the uncommon route variants.

Can also see a couple schedules from this route at that stop here: