Add caching for system_list()

probably slightly naive patch attached.

not sure if we want to use one cache rather than two, but lets start here.

wow, the lifecycle of $bootstrap_list and $lists inside system_list is, umm, not how it feels it should be.

hitting node/1, it goes something like:

1. drupal_bootstrap --> _drupal_bootstrap_page_cache --> drupal_bootstrap --> _drupal_bootstrap_variables --> module_load_all --> module_list -> drupal_static_reset('system_list')

2. drupal_bootstrap --> _drupal_bootstrap_page_cache --> drupal_bootstrap --> _drupal_bootstrap_variables --> module_load_all --> module_list --> system_list('bootstrap') --> fetches from cache, sets $lists['bootstrap'] --> returns it

3. drupal_bootstrap --> _drupal_bootstrap_page_header --> bootstrap_invoke_all --> module_list -> drupal_static_reset('system_list') --> who needed that bootstrap list anyway?

4. drupal_bootstrap --> _drupal_bootstrap_page_header --> bootstrap_invoke_all --> module_list --> system_list('bootstrap') --> fetches from cache, sets $lists['bootstrap'] --> woah, deja vu, returns it

5. drupal_bootstrap --> _drupal_bootstrap_full --> module_load_all --> module_list --> drupal_static_reset('system_list') --> who needed that bootstrap list anyway?

seems to behave as it should after that, the full list is built, on the next hit, and subsequent hits just return built bits without hitting the db.

do we need to worry about $list['bootstrap'] changing between _drupal_bootstrap_page_cache() and _drupal_bootstrap_page_header()? if not, then there's a db cache call (in the common case) we can get rid of we don't blow away the bootstrap cache in between those stages.

ok, lets see what the test bots of this simple patch, just don't blow away the bootstrap module list in _drupal_bootstrap_page_header.

not much of a gain, but its something.

ab -n200 -c2, APC on, hitting the front page, no nodes.

HEAD:
Requests per second: 10.61 [#/sec] (mean)
Requests per second: 10.71 [#/sec] (mean)
Requests per second: 10.63 [#/sec] (mean)
Requests per second: 10.63 [#/sec] (mean)

Patch:
Requests per second: 10.84 [#/sec] (mean)
Requests per second: 10.82 [#/sec] (mean)
Requests per second: 10.81 [#/sec] (mean)
Requests per second: 10.84 [#/sec] (mean)

work in progress, haven't integrated it with drupal_get_filename enough to get rid of the query there yet, so no need for careful review yet.

lets see what the bot thinks.

ok, test bot likes that much, setting to needs work because thats its real status.

more work in progress, definitely not working completely right, but i can't find tests that are broken, so lets get the bot to do it.

starting to make drupal_get_filename depend on system_list, stopping the 'prime drupal_get_filename' stuff.

thanks test bot. not good news though. i think BootstrapGetFilenameTestCase() is failing because its out of date: #642468: BootstrapGetFilenameTestCase is out of date.

assuming that is fixed, everything else passes, but when i check a fresh install with this patch, its wonky - admin theme is garland, and there are no blocks enabled at all. so, the patch passes all tests but is broken :-\

yes, i'd support that. drupal_get_filename() is just scary, and i think we get all the benefits anyway. i guess we'll have to leave to leave it as a steaming pile of .... along with module_list etc until D8.

lets see what the bot thinks of this. i've got tests running again and passing, but i haven't run the whole suite.

adds a system_list_reset() to _drupal_install_module(), which is a bit 'oh, that feels wrong but works', but anyway.

much better, changed drupal_static_reset('system_list') to system_list_reset() in list_themes() when $refresh = TRUE, and the failing tests pass locally for me.

lets see what the bot thinks.

comments-only update of the patch based on chx's comment and discussion with chx and catch in #drupal.