Error "The following module is missing from the file system"

Problem/Motivation

Coming from #2602032: Not working anymore with multiple bundles. Existing configuration in other bundles not detected..

• A fresh checkout of Features, Config Update, Drupal Core
• A "Bundle One" with a feature containing the Article content type.
• A "Bundle Two" with a feature containing the Basic page content type.

Error:

The following module is missing from the file system: bundle_one_bundle_two_page

The error occurs in these lines in FeaturesManager::listExtensionConfig():

      $extension = $bundle->getFullName($extension);
      $pathname = drupal_get_filename('module', $extension);

In the case that the extension name in $extension is already prefixed but with a bundle other than the current bundle, the current bundle is prepended to the name. Thus bundle_two_page becomes bundle_one_bundle_two_page

While in itself small, this issue reflects an underlying problem in handling the distinction between packages and exported features.

• For packages that we're potentially generating, we use short names. This is so that we have a common format for existing packages (which may have a bundle prefix) and detected ones (which don't yet have a prefix).
• In some cases, however, we read information about existing features regardless of whether they are part of our packages array. In these cases, we need to use full names for operations like reading from a module's configuration.
• Currently in several places we're mixing these use cases, such that we're mixing long and short names.

The current handling is complicated by several factors:

• In multiple places we use mixed arguments for extensions: either a string (machine name) or Extension object. There is not consistent handling of whether the string is a long or short name.
• Packages don't have a consistent set of properties. Instead, the properties present differ depending on which method was called to initiate the package.
• Bundle information is not consistently associated with a package, with the result that the current bundle is assumed, in some cases incorrectly.

Proposed resolution

• Convert all methods that accept Extension arguments to use an Extension type declaration rather than supporting mixed arguments.
• Rename FeaturesManager::getProject() to ::getPackageArray() and ensure that all properties are initialized. (This step should significantly facilitate our work in #2595263: Remodel packages as objects.)
• Where feasible and appropriate, use the package's 'extension' and 'bundle' properties.

To further aid code clarity and consistency (and, admittedly, miscellaneous cleanup ;)):

• Add missing use to features.drush.inc.
• Rename FeaturesManagerInterface::savePackage() to ::setPackage() to be consistent with other get/set pairs.
• Use Drupal::CORE_COMPATIBILITY constant in .info files rather than hard-coded string.
• Remove protected method FeaturesManager::getExtensionPath().
• Replace FeaturesManagerInterface::getExistingPackages() with FeaturesManagerInterface::getFeaturesModules().
• Raname FeaturesManagerInterface::initPackageFromInfo() to FeaturesManagerInterface::initPackageFromExtension().
• Remove protected method FeaturesManager::setPackageNames().
• Remove FeaturesManagerInterface::getModuleList().
• Tweak the handling of profile-provided configuration in FeaturesAssignmentExclude::assignPackages() such that (a) we always use the installed profile and (b) If the configuration has been assigned to a feature that's present on the file system, we don't make an exception for it. This addresses what appears as a bug, where already-assigned configuration shows up for reassignment; see #2602032: Not working anymore with multiple bundles. Existing configuration in other bundles not detected..

Remaining tasks

User interface changes

API changes

Data model changes