Error on generating features when "Include install profile" bundle option checked

Some quick background here.

Previously (in config_packager), the profile wasn't itself a package (that is, it wasn't part of the packages array), but was modelled similarly to packages, in a structured array that included the same keys. So, for example, files could be added to the profile, including configuration files, and the profile could be regenerated like a package.

This seems to have been lost in the conversion of profile handling to bundles.

I'll have a look at what's left to do here.

These changes are fairly extensive.

Background: in Configuration Packager, before it was merged into Features, I modelled the install profile separately from packages. Earlier in this issue, @mpotter began the work of refactoring so that the install profile is a special-cased package. This patch aims to compete that work.

The intended functionality is: when generating features, a site admin can choose whether to package them in an install profile. If this option is selected, generated features will be nested in 'profiles/[profilename]/modules'. If in addition the 'Profile' assignment plugin is enabled, a package will be generated for the install profile. If the install profile didn't already exist, it will be created drawing on code from core's standard install profile, including:

• Adapted code from standard.profile and standard.install, providing, ideally, a working install profile.
• Any configuration required by the code in standard.profile or standard.install. If this code has already been assigned to a feature, a dependency is created instead on that feature.
• Configuration from standard.info.yml including module and theme dependencies.

Currently, a number of issues are presenting, which this patch attempts to address:

• Two versions of the install profile are generated, in distinct directories (neither the correct one).
• The install profile is created with type: module in its info file rather than type: profile.
• The adapted versions of standard.profile and standard.install are not generated.

Minor updates to the previous patch (better reuse of new method FeaturesBundle::isProfilePackage()).

Explanation of some of the changes:

1. +++ b/modules/features_ui/src/Form/FeaturesExportForm.php
   @@ -420,7 +420,7 @@ class FeaturesExportForm extends FormBase {
   +      '#title' => array('#markup' => Xss::filterAdmin($package['description'])),
   

   Unrelated filtering fix.

2. +++ b/modules/features_ui/src/Form/FeaturesExportForm.php
   @@ -469,20 +469,6 @@ class FeaturesExportForm extends FormBase {
   -    if (!$current_bundle->isDefault()) {
   -      // Assign the selected bundle to the exports.
   -      $packages = $this->featuresManager->getPackages();
   -      foreach ($package_names as $index => $package_name) {
   -        // Rename package to use bundle prefix.
   -        $package = $packages[$package_name];
   -        unset($packages[$package_name]);
   -        $package['machine_name'] = $current_bundle->getFullName($package['machine_name']);
   -        $package['bundle'] = $current_bundle->getMachineName();
   -        $this->featuresManager->savePackage($package);
   -        $package_names[$index] = $package['machine_name'];
   -      }
   -    }
   -
   

   Since the renaming needs to happen via Drush as well as via the UI, moved this segment from the form to FeaturesGenerator::setPackageBundleNames().

3. +++ b/src/FeaturesGenerator.php
   @@ -126,10 +126,41 @@ class FeaturesGenerator implements FeaturesGeneratorInterface {
   +      $this->featuresManager->setPackages($packages);
   

   Need to reset the full packages array so that deletions are registered.

4. +++ b/src/FeaturesManager.php
   @@ -249,7 +249,6 @@ class FeaturesManager implements FeaturesManagerInterface {
   -      $this->addPackageFiles($package);
   

   We don't need to add files until just before generating.

5. +++ b/src/FeaturesManager.php
   @@ -751,15 +750,12 @@ class FeaturesManager implements FeaturesManagerInterface {
   -    unset($package['files']);
   

   An assignment plugin should be able to add files. Unsetting the files here removed files added by the profile assignment plugin.

6. +++ b/src/Plugin/FeaturesGeneration/FeaturesGenerationArchive.php
   @@ -102,14 +102,6 @@ class FeaturesGenerationArchive extends FeaturesGenerationMethodBase {
   -    // Add the Profile.
   -    if (isset($bundle) && $bundle->isProfile()) {
   -      $profile_package = $this->featuresManager->getPackage($bundle->getProfileName());
   -      if (!empty($profile_package)) {
   -        $this->generatePackage($return, $profile_package, $archiver);
   -      }
   -    }
   

   This was the source of duplicate profiles being generated. We no longer need to handle the profile separately since it's handled as one of the packages.

This completes the bulk of the refactoring. If and as further bugs show up we can open new issues.