Allow DAPR apps without a http endpoint to function correctly

[oising]

Description

The DAPR hosting WithDaprSideCar() expects the application to always expose a http endpoint. In the DAPR world, this is not the expectation. Only apps that expect to work with input bindings or subscribe to a pubsub topic (i.e. receive messages or events) are expected to have an http endpoint.

It seems a regression was introduced where an endpoint validation was previously a null check, and now it requires an IsAllocated boolean test. I also simplified the tests into patterns and unified the three checks across all three if statements checking appPort, appChannelAddress and appProtocol respectively.

I added a third "service C" to the playground app to validate that a service without an endpoint is successfully launched.

Unit tests (to come?) -- but they look pretty arcane. Might need some pointers.

Fixes #3687

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

[philliphoff]

Looks ok to me.

[davidfowl]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[davidfowl]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[oising]

@davidfowl -- will this make next release? It's a blocker for us. Thx!

[davidfowl]

It could, there's still time, my big concern is that we have no automated test coverage for dapr at the moment.

[davidfowl]

Spoke to the team and since we have little dapr test coverage at the moment I will merge this into main so that we can do more testing. Worst case is that we can back port to 9.0.1 if it doesn't make this release.

[oising]

Spoke to the team and since we have little dapr test coverage at the moment I will merge this into main so that we can do more testing. Worst case is that we can back port to 9.0.1 if it doesn't make this release.

I did add extend the playground app for it to verify, but yeah, I wish I could help more. Ultimately though, without this fix, the dapr support is very limited (without very disruptive workarounds)

[davidfowl]

Can you help verify 9.1.0 builds?

[oising]

Can you help verify 9.1.0 builds?

Yes @davidfowl -- what do you need me to do?

[davidfowl]

Verify that there are no regressions in using it with dapr.