Remove Dapr installation from Radius installation

[emily-potyraj]

As part of investigation into how to lower our Radius installation time #2582
we saw that Radius install time could be significantly reduced by not including Dapr installation.
At this time, we don't use Dapr internally as part of Radius, but we're considering it for a longer term possible change.

I think we'd need to do a little investigation into what it means to remove Dapr and what we'd need to add at that time to keep a great user experience.

Right now, Dapr is commonly used with Radius. We lean into teaching people that Dapr + Radius is a "better together" way of achieving portability. So Dapr installation is one of the common environment dependencies that Radius users are going to want.

When we stop installing Dapr by default, we should probably have the guardrails in place for validating whether environment dependencies are installed: dependency validation work described in #2951

AB#4448

[rynowak]

At this time, we don't use Dapr internally as part of Radius, but we're considering it for a longer term possible change.

I think we'd need to do a little investigation into what it means to remove Dapr and what we'd need to add at that time to keep a great user experience.

If we did take on Dapr as a dependency in Radius it needs to be firewalled from Dapr used by a user for applications (an implementation detail of Radius).

So, I don't think we should factor whether Radius uses Dapr into our decision. Dapr should be an optional component from the user's POV. If we were take responsibility for installing/managing Dapr for production use that's a huge deal 😆

When we stop installing Dapr by default, we should probably have the guardrails in place for validating whether environment dependencies are installed: dependency validation work described in #2951

Yes 100%. To treat Dapr as an optional component we need to design how users describe it to the environment, and how we implement guardrails for the user.