Allow object caches to degrade gracefully

[markjaquith]

Because of the way object caches are loaded, if a custom object cache can't run (say, Memcached or APC is not actually installed), it cannot gracefully degrade to the built-in object cache.

Witness this code in wp_start_object_cache():

 	if ( ! function_exists( 'wp_cache_init' ) ) {
		if ( file_exists( WP_CONTENT_DIR . '/object-cache.php' ) ) {
			require_once ( WP_CONTENT_DIR . '/object-cache.php' );
			$_wp_using_ext_object_cache = true;
		} else {
			require_once ( ABSPATH . WPINC . '/cache.php' );
			$_wp_using_ext_object_cache = false;
		}
		$first_init = true;
	} else if ( !$_wp_using_ext_object_cache && file_exists( WP_CONTENT_DIR . '/object-cache.php' ) ) {
		// Sometimes advanced-cache.php can load object-cache.php before it is loaded here.
		// This breaks the function_exists check above and can result in $_wp_using_ext_object_cache
		// being set incorrectly. Double check if an external cache exists.
		$_wp_using_ext_object_cache = true;
	}

So a custom object cache is loaded. If it wants to bail and defer to the built in object caching, it can do that by doing the include itself. But then WordPress sets $_wp_using_ext_object_cache = true; after that require. So WordPress thinks it is using an external object cache when it's actually not. This leads to oddness.

This can sometimes be hacked around by adding a callback to the very first WP action available that sets $_wp_using_ext_object_cache = false;, but that has issues: calls to the object cache might be made before that code can run, and add_action() is not always available at that point (because some advanced-cache.php drop-ins load the object cache really early. See Batcache.

Proposed solution: change the order of the require_once() and the setting of $_wp_using_ext_object_cache. That way, the external object cache can override the variable.

this is mildly related: #21401