PGOV-400: Config for deployment to cloud.gov

[acabouet]

This PR adds configuration and scripts for deploying the Drupal backend and the NextJS frontend of the PGOV MVP to the Cloud.gov environment using cloudfoundry cli.

In summary:

• manifest.yml is cloud.gov environment settings including the buildpacks we will use to build the frontend and backend.
• .bp-config folder contents (and apt.yml) are config for the PHP, NGINX, and apt (for dependency install) build packs
• bootstrap.sh is the script to install the drupal site, import existing config, optionally import a database, and complete migrations for files and media.
• bin/deploy-cloudgov.sh is a script that automates the creation of the services need for the backend to run (database, storage, secrets), setting necessary environment variables to pass to drupal install on the server, and then running the bootstrap script. You only need to run this if you've completed deleted the database, storage, and secrets containers on cloud.gov for some reason.

[vauxia]

Thank you for separating this out from site config stuff! It's much clearer.

This looks like this could use some streamlining. I'm going to try to make a branch from this branch to see if I can get it into alignment.

Here's the scoop: The PHP Buildpack ships with nginx as a web server. The expectation here is that we'd respect that choice, and set the site up using Nginx config files. In this scenario:

• .htaccess files get ignored and our overrides should go directly into the server configuration on nginx.
• Nginx configurations (easily identified by snake_case) persist, but Apache configurations (which use CamelCase) would go away.
• Basic auth needs to live in the nginx configuration and follow that format

I was confused about how any of this is working, but it appears that the apache2-utils package is brokering Apache-specific configurations into Nginx. Unless there's a use case that demands this, I would advocate for the removal of this dependency, and following nginx all the way.

I will try to take a swing at this.

[grugnog]

Digging into this a bit, I didn't make any real progress in switching to Nginx (and realized it's going to be hard without working CF env to test builds with).

However, I did do some digging into the php_buildpack and it looks like it can build with either Apache (AKA HTTPD) or Nginx out of the box and both have been been supported pretty much since the start - I don't think this is something we are installing.

As far as I can tell, Apache is the default (see WEB_SERVER here) and thus what we are using.
Looking at the configuration templates and docs I don't think they are doing anything weird in terms of both Nginx and Apache being used simultaneously via some kind of proxying or configuration translation. That said, it's a really big ball of yarn so it's kind of hard to tell without being able to look at what actually ends up running.

Given all this, and that Apache is currently working and well supported by Drupal I would suggest the simplest course of action is to try deleting the .bp-config/nginx/ directory, which I am guessing isn't actually doing anything. Nginx does have some advantages, but I don't think they are likely to apply to this site. If we need to do hardening/compliance Apache has an approved STIG and I am not sure Nginx does, which is a point in that direction also.

Unrelated to this, I am also wondering if we need https://github.com/cloudfoundry/apt-buildpack (unless one of the other buildpack depends on it) - we don't seem to be installing any packages currently.