Improve auto-forwarding for GitHub Codespaces and devcontainers.

[mitchdenny]

Description

This PR improves support for automatically forwarding ports for the following dev container scenarios:

1. GitHub Codespace via browser
2. GitHub Codespace via VSCode
3. Local Devcontainer via VSCode

This works by introducing a lifecycle hook that executes after endpoints are allocated. If execution within a codespace or local devcontainer is detected the hook will trigger the update to the machine wide settings.json file based on the configuration of endpoints within resources. In codespaces only http and https endpoints will be forwarded (developers can always set manual forwarding).

There is some timing sensitivity here. The settings file needs to be updated before it sees the endpoint in the console logs, if it doesn't there is a chance that the wrong protocol/label will be applied.

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):
      • [s] No
        • Link to aspire-docs issue (please use this doc-idea template):
  • No

Microsoft Reviewers: Open in CodeFlow

[davidfowl]

We can’t mutate global machine state from the apphost.

[mitchdenny]

We can’t mutate global machine state from the apphost.

I think this is the only way we can do it unless we are given an API.

[mitchdenny]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mitchdenny]

@davidfowl

[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]

Disabling a few flaky tests:
#6867
#6866

[davidfowl]

Why do we want to use this event instead of BeforeResourceStart? That way it's not blocking startup of the dashboard.

[mitchdenny]

It is important to dump out the port forwarded URLs as soon as possible after the ports are allocated so that no other log message triggers port forwarding before the port attributes details are written to the log file. Otherwise they'll be forwarded with incorrect attributes (label missing, incorrect protocol etc).

[mitchdenny]

Also even though this executes before the dashboard starts its a local I/O operation so not a huge impact to overall start performance. In my experimentation the dashboard is up and running before I've decided to interact with it.

[davidfowl]

Great work @mitchdenny !