Fix multimodal ferry reclassification

[kinkard]

Issue

Valhalla fails to take LeShuttle (tunnel between UK and France) for London -> Paris route - https://www.openstreetmap.org/directions?engine=fossgis_valhalla_car&route=51.50%2C-0.15%3B48.84%2C2.35#map=8/50.126/1.890

with a quite interesting expansion graph around the tunnel entrance

The reason for such behaviour is that ShortestPath() ferry connections reclassification algorithm might find a route, that is impossible to drive (e.g., an hgv-only edge, followed by non-hgv edge) due to exclusive access restrictions.

Solution

This PR adds NodeLabel::access property to track overall path access, accumulating it for both edges and nodes, fixing the "catch as match accesses as possible" iterations.

How London -> Paris route around LeShuttle looks like with this PR

Tasklist

• Add tests
• Add #fixes with the issue number that this PR addresses
• Update the docs with any new request parameters or changes to behavior described
• Update the changelog
• If you made changes to the lua files, update the taginfo too.

Requirements / Relations

Link any requirements here. Other pull requests this PR is based on?

This PR generalises the fix made in #4854

[kinkard]

Before this PR, in such cases, reclassification could find the shortest path for ABCDGHI with path_access == 0 (as BC is for hgv only and HI is for cars) and would stop there, unable to identify a better path.

[kinkard]

Previously only the path with overall_access_after == 0 has been found for LeShuttle entrance, preventing this algorithm from further iterations

[nilsnolde]

Yep, thanks, that makes sense to me! And makes the overall logic a bit saner as well:)

FWIW, @kevinkreiser had a wild idea a while back, where we'd ditch the entire reclassification (also for links) and simply move the roads in the hierarchies (without updating the classification). After all, that's all we want from it and it'd prevent problems further down, e.g. for openlr matching etc. I did that work in a private fork a while ago and it seemed to work. However, it was never merged bcs of all the potential (cross-team) problems for guidance, their openlr matching algo, visual tiles etc, which would have to be tested carefully. Good news is that the public project wouldn't be affected by that very much. Though RAD testing could also here come up with some diffs, it's possible our guidance code shows some adverse effects, maybe it's been working around the classification issues.. Also, I think in that case we wouldn't have to do this before building the graph, we could probably move it into the enhance stage and maybe consolidate a few of the routing algos there (not_thru & density also run one full planet expansion each).