Remove public methods from RouteProvider

Looks great!

@chx, @dawehner, @alexpott, and I discussed this issue a bit as an interesting borderline case for #2550249: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation.

I think we need to do one of:

1. Deprecating the methods for removal in 9.x. (Most BC.)
2. Marking the methods @internal, if we agree that methods not on the interface of a service should not be considered public API, as per the comment on #2550249-48: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation.

The impressive quantity of failures make me wonder though. :)

Turns out we use the route provider a lot. I think it's even more impressive the number of tests that passed!

+++ b/core/lib/Drupal/Core/Routing/RouteProvider.php
@@ -343,7 +343,14 @@ protected function getRoutesByPath($path) {
-    usort($routes, array($this, 'routeProviderRouteCompare'));
+    usort($routes, function(array $a, array $b) {

Making the method protected makes complete sense here, but why inline it entirely? I'm hardly one to object to anonymous functions in general but does this improve or harm readability if the function cannot be examined in isolation?

Otherwise +1 on making these methods less-accessible.

Right, *sort callbacks cannot be protected.

EDIT: Or can they?!?
https://3v4l.org/A4Mkc

https://3v4l.org/pG0M5 - Seems they can be protected. They just need to be accessible from the scope where the usort() is being run.

Well, let's try. And, for the record, I amended http://php.net/manual/en/language.types.callable.php

Accessing protected and private methods from within a class is allowed.

+1 from me.

So this doesn't do either of the things @alexpott and I recommended in #7. ;) Changing a method from public to protected is, in general, a BC break. Following the release of 8.0.0, we should not change public methods to protected unless the method is marked internal.

The case for allowing this change RC is:

• These methods are "implicitly" internal already--that the API is defined by RouteProviderInterface
• It's extremely unlikely there is any non-core code relying on them
• It's not doable in a patch release, and questionable for a minor, since it's not explicitly marked @internal.
• Reducing the API surface of the routing system is one of our priorities during RC.

Based on that, @effulgentsia and I decided to allow this change during RC. However, this is something of an exception--if it were after 8.0.0, or if they methods were even slightly less obscure, we'd probably lean toward not making the change without full BC.

So, committed and pushed to 8.0.x. Thanks everyone for weighing in on this!