Start to split AppExecutor, call events on restart of resources

[JamesNK]

Description

This PR is a start towards making ApplicationExecutor less of a monster. The new DcpExecutor is about 400 lines smaller.

• Add ApplicationOrchestrator. The orchestrator starts the DCP executor and subscribes to events from it. The orchestrator raises Aspire lifecycle events and publishes resource notifications. It handles managing parent/child notifications.
• Rename ApplicationExecutor to DcpExecutor.
• Add IDcpExecutor. Allows ApplicationOrchestrator to be tested independently.
• Add DcpExecutorEvents. Use by DCP executor to publish events and the orchestrator to subscribe. Copies what DistributedApplicationEventing does but much simplified.
• Add ResourceSnapshotPublisher. Moves building resource snapshots from DCP resources out into a seperate file.
• Add DcpHost. This splits the logic related to starting DCP process into its own file.
• Refactor DcpHostService into OrchestratorHostService. The orchestrator host service starts the DCP process using DcpHost then starts the orchestrator.
• Improved StartResourceAsync to call the OnResourceStarting event, which then triggers Aspire lifecycle events for the resource (BeforeResourceStartedEvent, waiting for health checks, etc)
• Improved StartResourceAsync to set a resource to FailedToStart state if there is an exeception.

TODO:

• Add tests for StartResourceAsync improvements

Fixes #7011

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
    • Is this introducing a breaking change?
      • Yes
        • Link to aspire-docs issue (please use this breaking-change template):
      • No
        • Link to aspire-docs issue (please use this doc-idea template):
  • No

[davidfowl]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[JamesNK]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[davidfowl]

Why didn't you use an interface here? Do we have multiple subscribers?

[JamesNK]

There are never multiple subscribers for these events. Just ApplicationOrchestrator uses this to listen to changes from DCP.

Are you asking about why not an interface for DcpExecutorEvents? There is only one implementation. The type could disappear and it becomes part of DcpExecutor/IDcpExecutor, but having it separated feels more usable in tests.

[davidfowl]

I’m asking why isn’t the dcp executor just calling interface methods to raise the events

[davidfowl]

Had an offline discussion with @JamesNK , this enables better testing and is incremental.