data-plane-controller for managing data-plane life cycles

[jgraettinger]

Description:

The controller uses the recent automations crate to monitor structured
changes to a bound data_planes and drive the data-plane to convergence.

It's modeled as a CI/CD pipeline, where an indicated branch of our
dry-dock repo (containing Pulumi and Ansible infrastructure) is deployed
for the given data-plane.

The controller performs the full lifecycle required for rolling updates:

• pulumi up to create new resources or respond to replacements
• Awaiting DNS propagation
• Running the Ansible playbook to provision instances
• Running pulumi up to reflect readiness of started instances
• Awaiting DNS propagation (again)

It also periodically refreshes a stack from remote providers to detect
changed or deleted resources, such as EC2 instance replacements, and
responds accordingly to heal the infrastructure.

A number of sanity-checks are built in to verify that we're modifying data-plane configurations in allowed ways, and that we're not performing modifications while the controller is actively driving the data-plane towards convergence.

The controller also publishes a variety of exported Pulumi outputs which customers need to know about, such as IAM users and GCP service accounts, AWS private link bindings, and VPC CIDR blocks.

Fixes #1727

Workflow steps:

(How does one use this feature, and how has it changed)

Documentation links affected:

(list any documentation links that you created, or existing ones that you've identified as needing updates, along with a brief description)

Notes for reviewers:

(anything that might help someone review this PR)

---

This change is 

[jgraettinger]

Testing

I performed extensive scenario testing against a private estuary_support/ data-plane in Vultr, including:

• Scaling up and scale-down of gazette and reactor deployments.
• Rolling upgrades by scaling up a new deployment, and then scaling down the old one for gazette and reactors.
• Adding a new Etcd deployment and scaling it down again. (note: etcd operations must be done one node at a time!)
• Deleting a gazette broker via the Vultr UI, and then allowing the controller to refresh and repair the data-plane.

I used the new command flowctl raw bearer-logs to stream logs of the controller's actions as they're happening.

I also spun up a local stack and verified the new pulumi_stack column is populated properly, and performed a publication with flowctl to verify that log streaming looks good 👍

[mdibaiee]

LGTM, left a nit/question and one sanity check suggestion