[REF] Ship Flexmailer extension with Core

[seamuslee001]

Overview

This ships flexmailer with core whilst still allowing sysadmins to enable it.

Before

Flexmailer not shipped with core

After

Flexmailer shipped with core

ping @totten @eileenmcnaughton this is as I believe we discussed

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

[eileenmcnaughton]

@seamuslee001 I think we should enable on install for new installs - but I'm happy for that to come later. Possibly even a release later since we need to do some checks about the path caching issue @jusfreeman mentioned

[mattwire]

@seamuslee001 I thought we were going to merge civicrm/org.civicrm.flexmailer#53 and resolve civicrm/org.civicrm.flexmailer#59 per https://lab.civicrm.org/dev/core/-/issues/1825 before moving this into core?

[mattwire]

Also ping @mlutfy ^

[seamuslee001]

@mattwire in the discussions I had had with Tim and Eileen they didn't raise those PRs I'm just trying to move this project along, either way I would be fine

[mlutfy]

Seems good to merge to core now, and change the setting in a subsequent release? (to do one big change at the time)

[mattwire]

@mlutfy Makes sense to change the setting later - but can we get the refactor PR merged before pulling into core? It reduces the code required by flexmailer and will need significant re-work to re-do it against core

[mlutfy]

Hmm true, I had assumed we would continue tracking PRs separately (in the flexmailer project), but there isn't any advantage to that..

[eileenmcnaughton]

@seamuslee001 style warnings... looks like you brought in pull 53 & we should ideally get this done before tomorrow's rc

[mlutfy]

We should test that this issue does not affect upgrades:
civicrm/org.civicrm.flexmailer#62

If we are renaming the extension, we might get away with it, since the old extension will be removed, cache flushed, then new one enabled.

[agileware-justin]

Mosaico has a dependency on Flexmailer, so how would the rename impact on Mosaico?

I would really like to test this change before it ships, recent issues with ExportUI and Flexmailer need to be avoided as much as possible.

For reference:

1. Just noting that when the last extension moved into Core, exportui caused a lot of "CiviCRM down" issues due to the location change.
2. Regression: "Uncaught Error: Class 'Civi\FlexMailer\Services' not found" - Caused CiviCRM outages
3. Fixes #61: partial revert the old autoloader to avoid cache problems

[eileenmcnaughton]

I'm going to merge this as merging it now will put it in the core tarball and we can discontinue the other repo. I note this has no code to enable the extension, either on install or on upgrade. I'm open to trying to leaving that until after the rc or fixing before the rc but merging this just means we have the code in the new place but are not (yet) determining which is enabled

[seamuslee001]

I would also add that my understanding is the following

1. the extension isn't getting renamed as part of this just the folder which has absolute no implications
2. If you have flexmailer already downloaded in your ext directory it should continue to use that version not the one that is shipped with core