Database is not upgraded in multisite if loopback is disabled

[creativeinfusion]

If on a server that disables loopback connections (like several shared hosting companies have implemented) when attempting to upgrade a WordPress Multisite the database is never upgraded from the normal upgrade process.

The normal upgrade process fails on the Network Upgrade wp_remote_get call with

Warning! Problem updating http://domain/subsite. Your server may not be able to connect to sites running on it. Error message: couldn't connect to host

The intent seems to be that logging in to the site(s) would fix it as the help on the Upgrade Network page (/network/upgrade.php?action=upgrade) says

If this process fails for any reason, users logging in to their sites will force the same update.

but although logging in attempts the update, that also fails (but silently) as it also fails on the wp_remote_get.

There's nothing that indicates the database version is out of step with the code and so no prompt. At least manually going to /wp-admin/upgrade.php and all /subsite/wp-admin/upgrade.php does fix it.

To replicate:
1) Get a server where loopback is disabled (or perhaps simulate it using the pre_http_request filter)
2) Install multisite using WP 3.0
3) Create a subsite
4) Upgrade to latest WP version using the link in the admin
5) Check the database version in the wp_options, wp_x_options table - or use this code to add the version into dashboard rightnow

add_action('rightnow_end','dbversion');
function dbversion(){
	$dbv = get_option('db_version');
	echo "DB Version: $dbv";
}

6) Log in/out to main site and subsite - database version remains at the old level
7) Manually visit the /subsite/wp-admin/upgrade.php page and upgrade it's database. The subsite db version will now be correct, but the main site will not until /wp-admin/upgrade.php is also visited

[creativeinfusion]

In principle in network/upgrade.php couldn't we call wp_upgrade() after the switch_to_blog() and avoid a wp_remote_get entirely?