Orchestrators and Operators

[mitchdenny]

Description

This PR is experimental and used to facilitate some discussion. At the moment the internal implementation of the app host has a few fundamental issues:

1. Some resources (such as child resources) don't have anything "driving" them. For example there isn't really a centralized place where we manage the state of a child resource - we instead expect the ApplicationExecutor and AzureProvisioner to just know to make sure that the child resource has the same state as the parent resource.
2. Startup blocks in that we wait for each resource to start before we consider the IHost "started".

I'd like to see us tackle these two issues. The goal of this PR is to explore this space. This PR will introduce two fundamental concepts:

1. The orchestrator; this is a top level singleton in the app host which is responsible for observing that a resource has been added to the model, and selecting an operator.
2. Operators; plugins to the app host which know how to handle resources of a particular type. The goal is to start to make resource start-up more reactive to app model changes and less a sequential thing where we spin up the app executor and provisioner. Instead the orchestrator will look at each resource and advertise to a singleton operator of each type that it is now responsible for a resource. The application executor would evolve into becoming an operator for containers and executables.

What does this do for us? Well it allows us to create a default built-in operator for IResourceWithParent resources (generics issue ahead here) - the built-in operator will simply make sure that the status is propagated UNLESS a specific provisioner is defined (probably via an annotation).

So far this PR doesn't have all of this. The first step is to build an orchestrator which is capable of observing that resources are added to the app model. I've done this by giving the resource collection an instance of the eventing singleton. In addition I've added a Queue method to queue events. The idea is that in the early stages of application startup we queue events that will then execute at the earliest possible moment in the applications lifecycle.

The handler for this event would resolve the operator for a resource and hand off ownership to that operator.

Fixes # (issue)

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue:
  • No

Microsoft Reviewers: Open in CodeFlow