Fix high walk reluctance leading to zero egress results for rental searches

[leonardehrenfried]

Summary

@binh-dam-ibigroup has reported that there are some cases where rental searches with a very high walk reluctance lead to zero egress legs.

After some investigation I found out that it's unfortunate chain circumstances that conspire to produce this problem.

• during the egress/arriveBy search the speculative rental states crowd out the regular walk states as they have such a high reluctance
• the speculative rental states reach the required number of stops but none of them are actually allowed to board the vehicle as no vehicle has been found
• the termination requirements are met but none of the states are usable for egress results

Luckily, there is a simple fix for the problem: when counting stops, also check State#isFinal to make sure that only allowable states count towards the number of stops.

This PR also contains small cleanups of the A* code.

Unit tests

✔️

Documentation

Lots of Javadoc added and updated.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (d71c768) 67.45% compared to head (8a67be4) 67.46%.
Report is 58 commits behind head on dev-2.x.

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #5605      +/-   ##
=============================================
+ Coverage      67.45%   67.46%   +0.01%     
- Complexity     16188    16196       +8     
=============================================
  Files           1862     1862              
  Lines          71184    71213      +29     
  Branches        7401     7406       +5     
=============================================
+ Hits           48019    48046      +27     
+ Misses         20674    20673       -1     
- Partials        2491     2494       +3     

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

[binh-dam-ibigroup]

I tested doing the original search that led to the issue and it seems to be fixed! Code changes are very clean.

[binh-dam-ibigroup]

The first part of this comment does not make sense.

[vesameskanen]

Nice that the fix is so simple! I verified that isFinal() call does not cause any significant routing time penalties.

[leonardehrenfried]

I also ran the speed test on the branch and could not see a slowdown.

[leonardehrenfried]

Since the only review comment was about Javadoc not making sense, I fixed it and have taken the liberty to merge without another round of review.