WaitFor/WaitForCompletion implementation.

[mitchdenny]

Description

This PR introduces two new extension APIs to the IResourceBuilder<T> interface:

namespace Aspire.Hosting;

public class ResourceBuilderExtensions
{
+    public static IResourceBuilder<T> WaitFor<T>(this IResourceBuilder<T> builder, IResourceBuilder<IResource> dependency) where T : IResource
+    public static IResourceBuilder<T> WaitForCompletion<T>(this IResourceBuilder<T> builder, IResourceBuilder<IResource> dependency) where T : IResource
}

Using these APIs it is possible to block the start of one resource depending on the start or completion of another resource.

var catalogDbApp = builder.AddProject<Projects.CatalogDb>("catalogdbapp")
                          .WithReference(catalogDb);

var catalogService = builder.AddProject<Projects.CatalogService>("catalogservice")
                            .WithReference(catalogDb)
                            .WithReplicas(2)
                            .WaitForCompletion(catalogDbApp);

The WaitFor(...) extension will wait until the resource enters the Running state, and the WaitForCompletion will wait until it is in the Finished state.

The WaitFor/WaitForCompletion methods build upon the eventing mechanism that was recently added. It waits for the resource started event and then uses the ResourceNotification service to wait until the resource reaches the desired state. In a subsequent PR we will build on this to support waiting until the resource is healthy in addition to just being in a running state.

Resources in a waiting state will have their state changed to Waiting with the same iconography as Starting (hence the small changes to dashboard/known state code).

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: [New article]: WaitFor/WaitForCompletion docs dotnet/docs-aspire#1556
  • No

Microsoft Reviewers: Open in CodeFlow

[mitchdenny]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mitchdenny]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mitchdenny]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[davidfowl]

Another downside to doing it this way instead of a single wait for callback with lots of data is that first one to throw will stop other errors from coming through since the wait is sequential.

[mitchdenny]

Maybe for this event we should invoke them all in parallel and then await them all together.

[radical]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mitchdenny]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).