Extensions - Setup <classloader> during "enable" and "uninstall"

[totten]

Overview

The builds on the theme of PR #20091. Recall from the previous PR that an extension might declare classloaders:

<classloader>
  <psr0 prefix="CRM_" path="" />
  <psr4 prefix="Civi\" path="Civi"/>
</classloader>

and then use them for installation:

function whizbang_civicrm_install() {
  \Civi\Whizbang\Setup::doInstall();
  \CRM_Whizbang_Setup::doInstall();
}

This PR extends classloading support to other stages of the lifecycle:

function whizbang_civicrm_enable() {
  \Civi\Whizbang\Setup::doEnable();
  \CRM_Whizbang_Setup::doEnable();
}

function whizbang_civicrm_disable() {
  \Civi\Whizbang\Setup::doDisable();
  \CRM_Whizbang_Setup::doDisable();
}

function whizbang_civicrm_uninstall() {
  \Civi\Whizbang\Setup::doUninstall();
  \CRM_Whizbang_Setup::doUninstall();
}

For a more complete example, see https://gist.github.com/totten/4864a530b078c6ea86b52d7b578d7c16

Before

Some of these workflows fail:

• ✔️ Enable WF: cv en whizbang
• 🔴 Re-enable WF: cv en whizbang && cv dis whizbang && cv en whizbang
• 🔴 Long uninstall WF: cv en whizbang && cv dis whizbang && cv ext:uninstall whizbang
• ✔️ Quick uninstall WF: cv en whizbang && cv ext:uninstall whizbang

After

All of these workflows pass:

• ✔️ Enable WF: cv en whizbang
• ✔️ Re-enable WF: cv en whizbang && cv dis whizbang && cv en whizbang
• ✔️ Long uninstall WF: cv en whizbang && cv dis whizbang && cv ext:uninstall whizbang
• ✔️ Quick uninstall WF: cv en whizbang && cv ext:uninstall whizbang

Technical Details

Why is this necessary? Recall that (for a typical admin) the lifecycle of an extension is:

1. Enable extension $x
2. Disable extension $x
3. Either:
   • (a) Re-enable extension $x
   • (b) Uninstall extension $x

Step #2 disables the classloader for purposes of regular page-loading. However, when you get to step #3a or #3b, then you need the classloader again. Of course, it would be premature to fully activate the extension (e.g. do not fire hook_civicrm_config on a disabled module). But you should have access to the classes.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[colemanw]

This makes sense & is well-documented.

[colemanw]

@totten test failures relate

[totten]

Yup. The failure in testInstall_DirtyRemove_Disable_Uninstall was relevant - it indicated that if someone did a "dirty removal" (deleting the code for an active extension), then one could get stuck (unable to disable the missing extension). Pushed a fix.