Fix rental searches when destination is in a no-drop-off zone

[tkalvas]

Summary

Fixes #6054

It turns out that the egress search ended up on a rental bike at all possible stops so StreetNearbyStopFinder.findNearbyStops didn't find anything. Based on my reading and debug runs, it is caused by the branch in StreetEdge.splitStatesAfterHavingExitedNoDropOffZoneWhenReverseSearching not having a walk state as one of the option.

I further think, but did not include in this PR, that the networks generated here should be filtered by what networks are allowed in the request. Now it generates everything allowed by the vertex, ignoring the request. This is not a correctness issue but affects performance.

Issue

Closes #6054

Also closes #6244

Unit tests

I added a short test which failed before but succeeds now.

Maybe there should be a larger scope test which replicates the situation as findNearestStops sees it?

Documentation

No changes.

Changelog

Changelog-worthy bug fix, maybe?

Bumping the serialization version id

No need.

[tkalvas]

Probably best reviewed by Leonard.

[codecov]

Codecov Report

Attention: Patch coverage is 75.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 69.73%. Comparing base (cee960f) to head (481c3b8).
Report is 322 commits behind head on dev-2.x.

Files with missing lines	Patch %	Lines
.../opentripplanner/street/model/edge/StreetEdge.java	75.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #6233      +/-   ##
=============================================
- Coverage      69.90%   69.73%   -0.17%     
+ Complexity     17723    17681      -42     
=============================================
  Files           1998     2007       +9     
  Lines          75443    75776     +333     
  Branches        7718     7755      +37     
=============================================
+ Hits           52740    52845     +105     
- Misses         20025    20218     +193     
- Partials        2678     2713      +35     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[leonardehrenfried]

So the problem appeared only when the destination of the routing request was in a no-drop-off zone?

[tkalvas]

Yeah, that is my understanding.

We might have a separate issue that a commercial operator's gbfs feed has spurious ride_allowed: falses. I'll have to track that separately. Anyway, that's probably why it was so hard to find a test case, it comes and goes for any particular coordinates in our production.

[tkalvas]

See an alternative fix #6244

Its discussion includes my motivation on why I don't prefer it.