Load additional profile directories via settings

Here is a patch that applies to 8.2.x. The only conflict from the previous issue thread patch was the comments added to ExtensionDiscovery.

Still need to add the tests using the virtual file system. But marking this for Review to see how the other Drupal automated tests work.

fix the patch with some changes.converted teh test to kernel test base
KernelTestBase will not remain in simpletest after 8.2.x #2734663: Update deprecation message for old KernelTestBase in simpletest :( so Moving to unit tests

Some minor corrections.

Starting to try and use this patch for a real distro and running into an issue.

If you try to enable modules in the base_profile in the main profile info.yml file, it seems to fail. When I look at my settings.php file, it isn't writeable so the code in the install.core.inc file wasn't able to take the base_profile from the info.yml and add the profile_directories line to the settings.php.

Tracked part of the problem down to drupal_check_profile() which loops through the dependencies and calls getPath on each one. At this early point of the profile install, nothing has been added to settings.php so the profile_directories haven't been added for the base profile. So if you reference a module within the base profile in the main profile.info.yml it will cause the error:

PHP Fatal error: Call to a member function getPath() on a non-object in /var/www/build/html/core/includes/install.inc on line 942

If I manually add the profile_directories array to settings.php then it gets past this error.

@mpotter just posted a patch which should solve this: #1356276-158: Allow profiles to define a base/parent profile

The patch in #158 of the parent issue #1356276: Allow profiles to define a base/parent profile is great for solving the overall profile inheritance issue. But the purpose of this issue is to split off the code that just sets the profile_directories via $settings into a simple issue that can easily be tested and applied to 8.2.x.

I have re-rolled the patch from #5 that has the new vfStream test (thanks abhishek-anand!!) and have removed the code that writes to the settings.php using the base_profile key. That kind of code needs to stay in the larger parent issue.

I think this is now nice and clean. We have a really straight-forward way to add additional paths to the settings for profile_directories. This code will be needed by the larger parent issue for inheriting profiles. We have a good test for it. Let's try to get this RTBC'd and into 8.2.x so we can focus effort on the larger parent issue.

Edited: To be really clear...all we are doing in this patch is implementing what the existing function setProfileDirectoriesFromSettings() implies that it should be doing.

This is looking good. Quite straightforward approach, and the added test illustrates the behavior.

A few tiny issues:

1. +++ b/core/modules/system/tests/src/Kernel/System/ExtensionDiscoveryProfilesTest.php
   @@ -0,0 +1,115 @@
   +  /**
   +   * Adds example files to the filesystem structure.
   +   *
   +   * @param array $filesystem_structure
   +   *
   +   * @return string[][]
   +   *   Format: $[$type][$name] = $yml_file
   +   *   E.g. $['module']['system'] = 'system.info.yml'
   +   */
   +  protected function populateFilesystemStructure(array &$filesystem_structure, $info_by_file) {
   

   Nit: one of the @params is missing, and they both need short descriptions.

2. +++ b/core/modules/system/tests/src/Kernel/System/ExtensionDiscoveryProfilesTest.php
   @@ -0,0 +1,115 @@
   +    unset($files_by_type_and_name_expected['module']['otherprofile_nested_module']);
   

   Can you add a code comment here to clarify why this is unset? It isn't immediately obvious I don't think.

3. +++ b/core/modules/system/tests/src/Kernel/System/ExtensionDiscoveryProfilesTest.php
   @@ -0,0 +1,115 @@
   +  /**
   +   * @param array $filesystem_structure
   +   * @param string[] $pieces
   +   *   Fragments of the file path.
   +   * @param string $content
   +   */
   +  protected function addFileToFilesystemStructure(array &$filesystem_structure, array $pieces, $content) {
   

   Similar to above, this needs @param descriptions, and also a short one-liner description at the top of the docblock.

The new approach I just posted to #1356276: Allow profiles to define a base/parent profile no longer actually uses this method. Will keep this open for a while longer but I think we've got a cleaner method now in the original issue.

This appears to be a duplicate of https://www.drupal.org/project/drupal/issues/3266057 which is way further along. Closing this one out and moving credit over.