Remove almost all file_exists() and is_file() calls from core

When Drupal includes files, it almost always test the file existence on disk. While I understand why this could have been a good idea, it is in reality almost always useless.

drupal_get_filename() relies on the system_list() function cache, which is prepopulated the first system_list() hit. Meanwhile, drupal_load() function relies on drupal_get_filename().

Those functions are called only in the context where both the module exists and the system database table is complete (and cached). The file_exists() calls are redundant and useless.

This has serious drawbacks, when you use a slow filesystem with a good OPCode cache, all file system calls are supposedly routed to the OPCode cache instead when including PHP files, which actually lives the file system alone. This is specifically true when you disable the stat command to be run by the OPCode cache.

Doing excessive file_exists() calls, you force the file system to do it twice (if the OPCode cache does stat() calls) and you explicitely wake up the file system. This is a serious performance problem especially on slow file systems.

This is quite a stupid thing to do, considering that Drupal knows the module list at all time, has it into database, and moreover does cache it with the system_list() function.

What I propose here is a simple patch that keeps the backward compatibility for contrib module, by adding new functions:

• module_load_system_include() as a replacement of module_load_include(), fully relying on system_list() cache, with no hits into the database nor the filesystem. Keeping the module_load_include() as-is for modules using it to attempt stupid file discovery using it.
• drupal_get_system_filename() as a replacement of drupal_get_filename(), fully relying on system_list() cache, with no hits into the database nor the filesystem. Keeping the drupal_get_filename() as-is for modules using it to attempt stupid file discovery using it.
• Some hacks inside the legacy functions to speed them up, testing first with the above functions if the file exists before trying to do any file system access.

And changing those details:

• At install time, prepopulates some essential modules into system_list() cache while the database isn't up.
• At install time, when database is up, fallback on normal behavior.
• Changed the module_enable() function behavior, clears the system_list() cache before actually loading the module files, which will allow the drupal_load() function to rely on a fresh rebuilt cache. This has no incidence on the core behavior.
• Aggregated both bootstrap and others system_list() cache entries into one, in order to ensure we'll have one and only one SQL or cache backend query in order to fetch all needed information.

Then fixes all core modules to use them in order to avoid excessive file_exists() calls (except in the update module which does some tricky install stuff without being properly enabled).

While doing this on a Vanilla core, this saves a lot of file system direct access. Even better, with a complex a big site, using Drupal Commerce, Rules, Views, CTools, etc... most of them have been ripped of, and everything is working fine, including install.

Notice that the core has a quite invasive patch, in order to have a positive impact all core modules must use the new functions and not the old ones.

Everything else works gracefully, legacy functions remain in order for contrib to have the right behavior.