Cache SystemMenuBlock and BookNavigationBlock per active trail (currently cached per URL, this breaks on very long URLs)

We can't use a cache context here - we have to decide it per block based on what menu name it's rendering.

Example code for getting the numeric active trail:

     $menu_tree = \Drupal::service('menu_link.tree')
    // Check if the active trail has been overridden for this menu tree.
    $active_path = $menu_tree->getPath($menu_name);
    // Parent mlids; used both as key and value to ensure uniqueness.
    // We always want all the top-level links with plid == 0.
    $active_trail = array(0 => 0);
    // If this page is accessible to the current user, build the tree
    // parameters accordingly.
    if ($page_not_403) {
       // Find a menu link corresponding to the current path. If
       // $active_path is NULL, let menu_link_get_preferred() determine
       // the path.
       if ($active_link = $this->menuLinkGetPreferred($menu_name, $active_path)) {
          if ($active_link['menu_name'] == $menu_name) {
            // Use all the coordinates, except the last one because
            // there can be no child beyond the last column.
            for ($i = 1; $i < MENU_MAX_DEPTH; $i++) {
              if ($active_link['p' . $i]) {
                $active_trail[$active_link['p' . $i]] = $active_link['p' . $i];
              }
            }
      }
  }

Implode the active trail, to get up 2 9 ints which can be part of the cache key.

In this context, it should be called something like the materialized path, not the "active trail".

fixes "Undefined variable: page_not_403"

Tried to figure out how things really work.

+++ b/core/modules/menu_link/lib/Drupal/menu_link/MenuTree.php
@@ -320,6 +301,39 @@ public function buildPageData($menu_name, $max_depth = NULL, $only_active_trail
+    $request = $this->requestStack->getCurrentRequest();
+
+    if ($route_name = $request->attributes->get(RouteObjectInterface::ROUTE_NAME)) {

I try to understand that check. What is the primary reason for that? Why should you ever have no route name on a page?

@dawehner - quite possibly this is a hold-over check from when some paths still used the old router? Also, that condition seems to be met for 404 pages?

Last patch has a bunch of unrelated changes like to EntityResolverManager extends ContainerAware

Oh yeah, I failed here. Here is a rerole with the interdfiff applied.

Alternate fix perhaps in issue 2224847

For cache hit efficiency this should be worth doing in its own right - the active trail can be identical for many, many different paths on a site.

Reviewed this and it looks really nice. Thanks for refactoring book module into the new system.

Committed/pushed to 8.x, thanks!