Use BeforeResourceStartedEvent instead of AfterEndpointsAllocatedEvent when scheduling setup before resource creation

[danegsta]

Description

We're using the AfterEndpointsAllocatedEvent in several places as a callback to do setup before resources are created. While it's true that historically AfterEndpointsAllocatedEvent has always been triggered before resources are created, that's mainly due to a limitation in the endpoints model (we don't currently support dynamically allocated host ports for un-proxied container endpoints).

The appropriate event to schedule additional model configuration before a resource is created is BeforeResourceStartedEvent which is sent just before the resource is created.

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
    • 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

[danegsta]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[davidfowl]

I don't think this works because the UI is a singleton that works with all of the target resources of that type.

[JamesNK]

BeforeResourceStartedEvent is now called when a resource is restarted. Keep in mind for whether this is a good change.

[danegsta]

BeforeResourceStartedEvent is now called when a resource is restarted. Keep in mind for whether this is a good change.

That depends on whether its consistently fired before the resource is created in the orchestrator. If so, it shouldn't cause any issues with these changes, we'd just do another pass of setup housekeeping before the new container gets created.