Allow disabling alterations to global tables during upgrade.

[ryan]

Sites that have large global tables (particularly users and usermeta) as well as sites that share their user tables with bbPress and other WP installs need to be able to prevent the WP upgrade from changing those tables during upgrade. An ALTER or an unbounded DELETE or UPDATE can take a long time to complete. Large sites usually want to avoid these being run as part of the WP upgrade so they can handle it themselves. Further, if you are sharing user tables between multiple bbPress and WP installs you might want one site to be the upgrade master. Let's introduce a DO_NOT_UPGRADE_GLOBAL_TABLES define that prevents dbDelta() and the upgrade functions from doing expensive queries against global tables.

[wpmuguru]

I like this. We do have to do something for network install which needs to add the spam & deleted columns to the user table.

[ryan]

(In [15375]) Introduce DO_NOT_UPGRADE_GLOBAL_TABLES. fixes #14221 for 3.0.1

[ryan]

[15374] for trunk.

[ryan]

Someone doing a network install needs to make sure DO_NOT_UPGRADE_GLOBAL_TABLES isn't set. Blocking an MS install from changing the user table is a primary motivation for this. :-)

[Denis-de-Bernardy]

I feel this is incomplete...

Imo, we should introduce a separate db version option, as in the db version of the global table, when this is around. When the define is present, the upgrader should supply some kind of link that forces the global table's upgrade to occur (aka once everything else is upgraded properly), and upgrade this option accordingly once the global tables are indeed upgraded.

[johnjamesjacoby]

Related: #32154

[spacedmonkey]

Related: #32011