Multi-leg nearby coordinate lookups.

[JThramer]

Fixes #1879. Allows for look-behind when you're on the first step of a leg, and look-ahead when you're on the last step.

/cc @mapbox/navigation-ios

[akitchen]

Does it make sense to keep the currentLegProgress.nearbyCoordinates in addition to the new routeProgress.nearbyCoordinates? should we be deprecating the older one?

also, the B in nearby should be a small b, but that's ultra-minor

[JThramer]

I've no real feeling on the subject either way, but @1ec5 did argue for keeping it the other day, and his rationale (which I cannot remember OOTOMH) made sense to me.

[1ec5]

I had assumed that nearbyCoordinates would become yet another aggregate property along the lines of remainingDistance. But nearbyCoordinates can’t be aggregated; it’s actually more of a view into the overall route geometry, along the lines of Route.polylineAroundManeuver(legIndex:stepIndex:distance:).

Put another way, when we want the route’s remainingDistance, we can add in the remaining legs wholesale; we don’t need step-level granularity for other legs. But with nearbyCoordinates, we’re always working at a step level, but the method now goes on RouteProgress because we’re trying to erase the boundaries between legs.

The current implementation of this PR still relies on RouteLegProgress.nearbyCoordinates, but my suggestion in #1883 (review) shows that we can achieve a more elegant implementation without it. Therefore, I’m 👍 on deprecating RouteLegProgress.nearbyCoordinates.

[1ec5]

The progress classes were designed from the beginning around a divide-and-conquer strategy, with each computed property functioning as an aggregator. But increasingly we’re asking RouteStepProgress for information that erases the boundaries between legs, which calls into question this strategy, given that we already retain the entire route geometry in memory. A different approach would’ve been to map each of the steps to its starting coordinate index when getting a new route. Then this sort of “nearby” query would be just a single index into the master route geometry and working forwards and backwards from there.

All that can wait. What we have here is functional, though I’ve left comments for making it more self-documenting and easier to piggyback on for additional features.

[1ec5]

This is still fixed, but via this PR rather than #1869.