autoloader: Preload classes on plugin upgrade to avoid mid-upgrade fatals

[anomiex]

Changes proposed in this Pull Request:

It's possible that the new version of the plugin will move some files
around that some later hook will try to load, causing a fatal as the
autoloader will still be looking in the old path. To avoid this, have
the Jetpack autoloader detect when an upgrade is happening and pre-load
all the classes in the plugin.

We do the same for plugin removal, for similar reasons.

Note this doesn't work for classes loaded via PSR-0 or PSR-4. But that
shouldn't matter for us since we always generate an optimized (classmap)
autoloader for releases of our plugins.

Also of note is that this won't work if you're manually installing a
specific version of the plugin as wp plugin install jetpack --version=10.5,
as wp-cli does that as an "install" rather than an "upgrade" operation.

Jetpack product discussion

p9dueE-4c4-p2

Does this pull request change what data or activity we track or use?

No

Testing instructions:

• Create a fresh site, e.g. with JN.
• Use Jetpack Beta to downgrade Jetpack to 10.4, and to install the release version of itself. Uninstall any other monorepo plugins. Also delete any wp-content/plugins/*-dev, just to be sure.
• Connect Jetpack (sync won't try to sync post-upgrade if you don't).
• Add the following mu-plugin:

  <?php
  add_filter( 'pre_set_site_transient_update_plugins', function ( $transient ) {
  	if ( isset( $transient->response['jetpack/jetpack.php'] ) ) {
  		$transient->response['jetpack/jetpack.php']->new_version = '10.5';
  		$transient->response['jetpack/jetpack.php']->package = "https://downloads.wordpress.org/plugin/jetpack.10.5.zip";
  	}
  	return $transient;
  } );

• At this point the plugins page and wp plugin upgrade should both want to upgrade Jetpack to 10.5. Doing so should give a mid-upgrade fatal as described in p9dueE-4c4-p2.
• Re-install Jetpack 10.4.
• Use Jetpack Beta to check out the version of Jetpack Beta from this PR.
  • Optional: wp shell <<<'spl_autoload_functions()[0];' should indicate that it's using Automattic\Jetpack\Autoloader\jp567fa3f555de8fd218dfdc1688bb97b5_betaⓥ3_1_1_alpha\PHP_Autoloader.
• Now upgrading via the plugins page or wp plugin upgrade should succeed without a mid-upgrade fatal.

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ All commits were linted before commit.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team review" label and ask someone from your team review the code.
Once you’ve done so, switch to the "[Status] Needs Review" label; someone from Jetpack Crew will then review this PR and merge it to be included in the next Jetpack release.

---

Beta plugin:

• Next scheduled release: April 5, 2022.
• Scheduled code freeze: March 28, 2022.

---

Jetpack plugin:

• Next scheduled release: April 5, 2022.
• Scheduled code freeze: March 29, 2022.

---

Backup plugin:

• Next scheduled release: April 5, 2022.
• Scheduled code freeze: March 28, 2022.

---

Vaultpress plugin:

• Next scheduled release: April 5, 2022.
• Scheduled code freeze: March 28, 2022.

---

Boost plugin:

• Next scheduled release: March 28, 2022.
• Scheduled code freeze: March 21, 2022.

[fgiannar]

Hi Brad,

I tested using your instructions and everything works as expected as far as updating from JP 10.4 to JP 10.5 is concerned.
However, after successfully updating to 10.5 I removed the mu-plugin and tried updating to JP 10.6
This produced the following fatal:

PHP Fatal error:  require(): Failed opening required '(redacted)/public/wp-content/plugins/jetpack/vendor/automattic/jetpack-composer-plugin/src/class-plugin.php' (include_path='.:/opt/sp/php7.4/lib/php') in (redacted)/public/wp-content/plugins/jetpack-beta-dev/vendor/jetpack-autoloader/class-php-autoloader.php on line 90

[anomiex]

Good find! When we added the composer-plugin we didn't bother including it in the plugin bundle, but the autoloader still "knows" about its classes. Normally that doesn't matter since we don't actually load those classes, but this PR would try loading them.

Should be fixed now.

[kbrown9]

This approach looks good to me. As expected, commit 0981b47 did resolve the issue with attempting to load files that aren’t in the release in my tests.

[fgiannar]

👍 Thanks for working on this! I repeated the testing instructions, plus attempting to update to 10.6 and 10.7 and succeeded without any errors.

[anomiex]

Needs re-approval after version bump