[REF] Alter new Setup process to use CiviCRM's Event Dispatcher

[seamuslee001]

Overview

This changes CiviSetup to use Civi Core's event dispatcher

Before

Uses the EventDispatcher directly

After

Uses the CiviCore Event dispatcher which currently extends off of the Symfony Event DIspatcher

ping @totten @demeritcowboy

[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).

[seamuslee001]

also ping @kcristiano

[demeritcowboy]

My guess given that setup sometimes duplicates code found elsewhere is that there was a desire to minimize dependence on something that hasn't been installed/bootstrapped yet. But it does already call some civi things so I can just give it a quick test to see.

[demeritcowboy]

And just to clarify the description this was in the context of drupal 9 using a newer symfony which annoyingly switches the order of parameters giving deprecation notices.

[demeritcowboy]

Runs ok for me.

[totten]

Most of the added bits in CiviEventDispatcher should be safe in de-minimis/non-booted/foreign environments - e.g. the dispatch-policy stuff and the variations on adding-listerners/subscribers are fairly internal/clean.

I was slightly concerned about the class being available -- but the setup protocol specifies that Civi classes shall be loadable before we get here (ie before Step 3 - Civi\Setup::init()). So that's fine.

As currently written, the part to watch out for is delegateToUF() - that gets wrapped up with various globals/singletons/DB-content/file-loads. If delegateToUF() was called inadvertently or prematurely (ie before Civi is installed), then you could get Strange Things.

Fortunately, the setup-dispatcher doesn't actually call delegateToUF(). All its events fall under civi.setup.*. The risk is that Future Developer gets confused about the two dispatchers (setup-dispatcher vs runtime-dispatcher). This seems like a simple defense/mitigation:

    self::$instance->dispatcher = new  CiviEventDispatcher();
    self::$instance->dispatcher->setDispatchPolicy(['/^civi\.setup\./' => 'run', '/./' => 'fail']);

[seamuslee001]

ok I have applied that additional guard from Tim and I think this is right to be merged now

[demeritcowboy]

Runs ok for me.
Also ran uninstall.