Drupal\Core\Routing\RouteProvider::getCandidateOutlines() does an illegal shift when config is empty

Patch to show the error.

The 5.x fail actually holds a clue. This was wrong all along but not the shift, the bug is in the optimized mask generations. Lets look at the code:

    // The highest possible mask is a 1 bit for every part of the path. We will
    // check every value down from there to generate a possible outline.
    if ($number_parts == 1) {
      $masks = array(1);
    }
    elseif ($number_parts <= 3) {
      // Optimization - don't query the state system for short paths. This also
      // insulates against the state entry for masks going missing for common
      // user-facing paths since we generate all values without checking state.
      $masks = range($end, 1);
    }
    elseif ($number_parts <= 0) {
      // No path can match, short-circuit the process.
      $masks = array();
    }
    else {
      // Get the actual patterns that exist out of state.
      $masks = (array) $this->state->get('routing.menu_masks.' . $this->tableName, array());
    }

We're focused on the 2nd and 3rd cases. The first case matches everything less then 2nd matches everything <= 3 and the second matches everything <= 0. Obviously the 3rd if never gets matched but its important that it does. It exists because when $end <= 0 assumptions fall apart and and the safe guards in mask loop that happens next fail.

Because the optimized version of the mask generation doesn't exist in 7, its not affected and this is only a 8.x problem.

Forgot the comment sorry. So the idea here is we want to make sure we only return routeable paths. So thinking about what an empty config return means, we have 2 possibilities.

1. Best case, someone hand entered an invalid value and the site works but the frontpage is broken.
2. Worst case, the config is broken and any URL will fail.

So, I think the options are to hard code a fallback or throw an exception. Since broken config is going to cause the site to be broken anywhere else, I went with throwing the exception in this patch. Lets see what the rest of the test suite thinks about it.

Apparently the failure was @group missing. The failure return code broke something in drupalci and something something so the message was lost but Mixologic committed a fix and people shouldn't see it in the future.

Added some docs and fixed the test.