Enforce some of our strictest update checks only for background updates

[nacin]

We need to make sure we don't accidentally prevent someone from ever being able to update, even when they click "Update Now."

It is really important to only update automatically in the background when we are absolutely positive we can be successful. But, some checks could be a little overeager. There are two I'm thinking of, in particular:

• disk_free_space() is enforced in unzip_file(). If there is a bug in any code prior to wp-admin/includes/update-core.php being included that prevents an update, we are completely screwed — they'll be stuck on that release forever.

• The files_not_writable protection does happen inside wp-admin/includes/update-core.php, so if we're overzealous, a new release can fix it. That said, if there's a single file we can't copy (some random TinyMCE image or something), the site isn't actually affected, but we'd block the entire update from continuing. For background updates, this is very good. For manual updates, it's possible that we actually would *prefer* for the update to occur, and fail, than for the user to not actually be able to update at all. We also do a disk_free_space() check later on, prior to performing a last-resort copy.

What I'd like to do is two-fold:

• Only enforce disk_free_space() (and other pre-update-core.php checks) if we are DOING_CRON.

• Do a pretty basic 3.7.1 update with some bug fixes as a "test" for how successful our updates are.

There hasn't actually been any files_not_writable failures since 3.7-RC1, so I think we can leave that as-is for now. However, we should vastly improve our error messages (yes, for 3.7).

[dd32]

25652.diff​ moves the disk_free_space() check in unzip_file() into a DOING_CRON check.
We had previously talked about making it a warning for non-background updates, but I can't see an easy way to do that unfortunately.

For the files_not_writable one, currently the major thing it'd catch is someone running a svn up as root and later trying to update as a regular user (not that the update would succeed in that case anyway).

25652.2.diff​ does as we've discussed previously to simply display it as an alert and not a failing case, this isn't designed for committing, more a talking point.
I personally don't think we need to change this behaviour right now, half updating WordPress (even TinyMCE files) leads to user confusion and "broken sites" (ie. Visual editor not working correctly), just because the site doesn't fatal, doesn't mean it's not "broken" to a user.

[nacin]

Let's do 25652.2.diff​. That said, we need to improve the files_not_writable string. Yes, willing to make a string change for that.

[nacin]

25652.3.diff​ updates a string, uses it in a few places, and makes sure that the right error data gets passed into a few objects that way the affected files are shown to the user. (Good for when files_not_writable catches some random TinyMCE .html file.)

New string: "The update cannot be installed because we will be unable to copy certain files. This is usually due to inconsistent file permissions."

[nacin]

In 25869:

Only enforce disk free space checks when doing background updates.

see #25652.

[nacin]

In 25870:

New, better error message when we realize we won't be able to copy a file and continue with the update.

fixes #25652.

[nacin]

props dd32 on [25869]

[nacin]

In 25871:

"some files" instead of "certain files". Less stuffy.

props markjaquith.
see #25652.