Introduce hook_menu_router_update()

And as said, this thing is "pending" until #512962: Optimize menu_router_build() / _menu_router_save() is fixed.
Until then I will not produce any patches, and I don't want to see anyone else uploading one.

That said, we can already do some bikeshedding and "sub" and "+1".

We could make a first version of this thing, that takes the complete $menu array with all router items, instead of the $insert and $udpate and $delete.
We need this anyway, because in some cases we might not have the diff available. That is, if the menu_router table was corrupted, and or overly crowded, then we might prefer a clean rebuild from scratch, instead of the diff.

What should be the modules that implement this hook?

Long-term (but still D8):
- "menu_links" module defines the menu_links table and infrastructure, and the blocks that render the menus (currently in "system" or core menu.inc).
- "menu_links_ui" module for the admin ui for menus based on menu_links (currently "menu" module).
- "navigation" module for the navigation menu.

Short-term:
- "menu" does what it already does.
- "navigation" module for the navigation menu.
- anything in core that depends on the navigation menu (breadcrumbs, tabs?), needs liberation from this dependency.

In both cases, it would be the "navigation" module that implements the hook_menu_router_update().

Very short-term:
- "menu" does what it already does.
- "system" implements hook_menu_router_update() to fill the navigation menu.

I overlooked some details.

_menu_navigation_links_rebuild() does not only rebuild the navigation menu, it builds a whole bunch of menus.
Some key router items (such as 'admin') have a menu name set, which determines the menu for all their child items.

Thus, we can no longer follow the approach that one generated menu is "owned" by a specific module, and each of these modules could rebuild the menus that it owns, independently. This would be even slower than building them all at once.

Conclusion:
The refactoring approach suggested above does not make sense within the current system.
_menu_navigation_links_rebuild() shall remain in core for now.
But, this does not mean it cannot be optimized for a diff-based rebuild! And in general, a more reliable logic.

Going to postpone this for now, until someone else has an opinion.

I'm goint to re-open this.

Re #5:
Yes, the "one generated menu is owned by a specific module" is not the approach to take.
But, we can still decouple _menu_navigation_links_rebuild() by introducing the hook.

D7 vs D8:
I expect that D8 will soon revamp this area altogether.
The new hook would still be useful for D7.

So, the plan could be:
1. Introduce the hook in D8.
2. Backport to D7.
3. Revamp this stuff in D8, which might kill the hook.

Here is a minimal patch, which moves only this one operation from menu.inc into system.module as a hook implementation.

Profit:
- Modules can use hook_module_implements_alter() to kick system_menu_router_update().
- Modules can implement hook_menu_router_update() themselves for whatever they need it for.

Note: I put this in system.module, not in menu.module, because menu.module is only supposed to provide the admin UI for menu links.
The menu_links table is defined in system_schema(), not in menu_schema().

#10 yup.
if enough people want this, we do the homework.

what about a bit of bikeshedding on the hook name?
hook_menu_router_update()
hook_menu_router_updated()
hook_menu_router_rebuilt()
hook_menu_router_changed()

One idea was to use this past tense to indicate that something happened, instead of something currently happening or about to happen. Also, "rebuilt" is so awkward that it seems quite safe against nameclash :)

---------

Another thought.

I would like to move to a diff-based menu_router rebuild at some day. Once we are there, there will be two cases for this hook to fire: (1) full rebuild from scratch, if no previous data is available. (2) Rebuild with diff.

We could extend the hook like this:

function hook_menu_router_update($menu_router, $inserted = NULL, $updated = NULL, $deleted = NULL) {
  ..
}

or stuff those three extra arguments into an object / array.
The first argument would still be there, for implementors that cannot handle the diff.

The point is, we can add this extra magic as a follow-up, without breaking anything.

Another thing to bikeshed:
Which module should "own" the default hook implementation? System, as it is proposed in the patch?

Also, should the hook really be owned by menu? with menu.api.php?
In D7 at least, menu module only makes the UI, while menu_links are in system.

So... start in system/core, and move this stuff to a dedicated module as a follow-up?

First: I want this in D7, too.
Second: The silence on #1835902: Allow modules to register links for menus, breadcrumbs and tabs (if not with hook_menu) makes me think of the underpants gnomes.
1. Collect underpants.
2. ?
3. Profit.

We could have made a lot of progress on the existing system, if it was not for this dark hole.

EDIT:
And seriously that's the same on IRC, noone really knows where this is heading.
If we officially knew the way that D8 is going to take beyond just "symfony does our routing", we could directly go to D7 with issues like this one.
Personally I can not think of anything that is not a DX regression compared to hook_menu().

Would this still make sense for D8, in a different way?
We do have a route building on D8, and we could fire an event when this is finished, so dependent systems could do their own rebuild.