Use Composer to install recipes that are not already present in the code base

Problem/Motivation

We've been building to this for a long time.

Drupal CMS currently ships the Byte template among its dependencies, even if you don't actually intend to use it. That's because, at install time, we don't have a way to bring in site templates (or indeed, any other recipe) you choose.

I think we can make that happen.

Proposed resolution

Recipe Installer Kit lets you build up a list of recipes you want to apply. That list gets propagated in the recipes query string parameter -- it's a list of Composer package names.

As we loop through this list, we should check to see if the package exists in the code base already (i.e., it exists at the expected path). If it does, we convert it to batch operations and add it to the overall batch job, exactly as we do now.

But if it doesn't, we should add a batch operation that uses Composer to install the recipe: composer require --minimal-changes --update-with-all-dependencies PACKAGE_NAME, and when that succeeds, it converts the recipe to batch operations and appends a new batch job to apply it.

If the Composer operation fails, then it will just crap out with an exception, as would any other failed batch operation.

We will not use Package Manager for this -- at least, not at this time. Why not? Because, in the installer, we don't need most of what Package Manager gives us:

• We're only installing stuff, not updating anything that is existing.
• Even if something we're already running gets updated, there is no Drupal site yet to break -- we're still in the middle of installing it!
• We'll use --minimal-changes to reduce the possibility of running code getting updated.
• To further reduce the possibility of breaking running code, all Composer operations will happen before the operations that change runtime state -- that is, before the recipes are actually applied.

Most of the validators that ship with Package Manager -- save for maybe a few of them (WritableFilesystemValidator, DiskSpaceValidator, and MultisiteValidator spring to mind) -- are largely irrelevant whilst installing Drupal.

Furthermore, Package Manager's sandboxing capabilities are mostly there to avoid breaking a fully built, operational site. In the installer, that assumption doesn't hold. It especially doesn't hold if you're only adding packages, not changing them -- and indeed, that's the reason why Package Manager's direct-write mode was added. But Package Manager is very heavy, and very slow, and it doesn't give us much value in the installer. So we can just skip it and do Composer stuff directly.

This would not prevent PHP-TUF from playing, either. TUF operates at the Composer level and has no technical relationship to Package Manager.