feat: optionally use OpenTripPlanner for nearby transit

[boringcactus]

Asana task: [Backend] Endpoint for stops + routes near given location

I think having the source of stop info as a parameter might make some sense while we're still figuring out how we want to approach nearby stop sorting and filtering.

As mentioned in the Asana comments, the OpenTripPlanner route pattern info is somewhat mangled compared to the GTFS values, so I'm not using it here, but I split that decision into its own commit so it's easier to roll back if we decide we want to.

Running this in production will require configuring the OTP_URL environment variable.

This OpenTripPlanner client is derived approximately from #34, and so also from dotcom.

[KaylaBrady]

This looks good! Added a few small suggestions

[KaylaBrady]

suggestion: I find this function a bit hard to read with the nesting, but it may also be because I am less familiar with the for comprehension than reducing via enum.

Could this perhaps be broken into smaller steps, or use more piped steps? The single pipe on line 21 into a case with only one condition is a bit confusing as well - could pattern matching be used here if there is only one case?

[boringcactus]

The idea here was to implement a skeleton on top of which we can build error handling without having to rearchitect all this code, but with no actual error handling it's just harder to read for no reason. Conveniently, in my visualization work I encountered the problem of Massport shuttle stops being neither errors nor success, so it's worth fleshing this out somewhat to ensure those stops are correctly filtered out.

[KaylaBrady]

I don't know much about the massport shuttle and the expectations for whether or not it would show up in nearby transit - filtering seems reasonable for now, but can you ask product/design if you haven't done so already about how to handle them?

[boringcactus]

Asked in Slack.

[KaylaBrady]

suggestion: could you please add a case where there is a stop that has a parentStation?

[boringcactus]

Yes.

[KaylaBrady]

👍 this is a nice approach while we're in the testing phase! Can you please add a ticket to the backlog so we can revisit what to do here once we've learned more? Do we want to remove one entirely? Do we want to keep both options and have configuration on the backend so that we can make a switch between the two with a deploy if needed?

[boringcactus]

https://app.asana.com/0/1205425564113216/1206433651837131/f

[github-actions]

Coverage of commit 3ba001e

Summary coverage rate:
  lines......: 59.0% (350 of 593 lines)
  functions..: 59.9% (170 of 284 functions)
  branches...: no data found

Files changed coverage rate:
                                                             |Lines       |Functions  |Branches    
  Filename                                                   |Rate     Num|Rate    Num|Rate     Num
  =================================================================================================
  lib/mobile_app_backend_web/controllers/nearby_controller.ex| 100%     20|88.9%     9|    -      0
  lib/open_trip_planner_client.ex                            |68.8%     16|80.0%     5|    -      0
  lib/open_trip_planner_client/nearby.ex                     |81.8%     22| 100%     7|    -      0
  test/support/data.ex                                       |38.0%    100|68.4%    19|    -      0

Download coverage report

[boringcactus]

The [Nearby Transit] Update radius & sort order ticket can include flipping the default source back to V3.