DT-588: New projects use Composer Scaffold.

[danepowell]

Fixes #3563

Composer Scaffold replaces and deprecates the older Drupal Scaffold as of Drupal 8.8. However, the two packages conflict and since only Drupal Scaffold is available prior to 8.8, some accommodations have to be made. Namely, we have to disable the ORCA "previous Drupal release" test until Drupal 8.9 is released. This is fine since in real-world usage, customers are unlikely to be creating new Drupal 8.7 projects.

Note that this PR only affects new projects. Existing Drupal 8.7 users can still update to BLT 11, or add BLT 11 to their projects.

Changes proposed

• Update template composer.json to use acquia/composer-scaffold instead of drupal-scaffold, which pulls in Composer Scaffold.
• Update template composer.json extra config as necessary to work with Composer Scaffold.
• Remove template files that are now managed by Composer Scaffold
• Fix ACSF commands to work with Composer Scaffold.

Steps to replicate the issue

1. Copy blt-project template to tmp directory, due to Composer limitation: cp -r subtree-splits/blt-project /tmp/
2. Tell Composer to use your local blt-project: composer config --global repositories.blt-project path /tmp/blt-project
3. Tell Composer to use your local blt: composer config --global repositories.blt path /home/dane/packages/blt
4. Test creating a new project: composer create-project --no-interaction acquia/blt-project:dev-master
5. Ensure the newly create project functions normally.
6. Restore your global Composer config: composer config --global --unset repositories.blt && composer config --global --unset repositories.blt-project

[danepowell]

This "dependency" only existed to support PHP 5.6, so it's safe to remove: #1829

[danepowell]

@TravisCarden I have a conundrum. This PR is changing BLT's project template to use Composer Scaffold, which is only available in Drupal 8.8. Thus you cannot create Drupal 8.7 projects anymore. From a customer standpoint, I think that's fine (no one wants to create new projects on an old version of core.) But this causes ORCA's previous version test to choke.

Any ideas how to solve this? To solve this in the spirit of ORCA, for the previous version test, it seems like you'd want to test that you can add BLT to an existing Drupal 8.7 project (which is possible), rather than testing that you can create a new Drupal 8.7 project with BLT (which is not possible). But that's a pretty big architectural change for ORCA.

[TravisCarden]

Well, @danepowell, ORCA's policy is to test all supported scenarios. (See, for example, how Lightning Core 8.x-3.x only runs a couple of jobs.) So if you can't create a new BLT site on Drupal 8.7, then you don't need to. On the other hand, as you point out, BLT has functions independent of new site creation that should continue to work and are still supported. If (as you will know better than I) you have a clean version break for core version support (e.g., 10.x supports <8.8.0 and 11.x support >=8.8.0) then you can just run the appropriate tests on each branch. Lightning has such a branching strategy, as can be seen for example in Lightning Core's Branch Compabitility table. If you don't currently take such an approach, you might consider it. As far as I've thought it through, it's about the only sane solution within the current constraints of ORCA's design.

[danepowell]

Thanks. It's not ideal but I agree that just killing that test is the best approach for now. Done and done.

[alexxed]

🎉