Trouble with Dapr auth when api versioning and default policy is in place.

Wasn't sure what to post this under, so created a general discussion.

### Dapr conflicting with in place authorization policy

When calling in Startup

```
serviceCollection.AddDaprClient();

serviceCollection.AddAuthentication("Dapr").AddDapr();

serviceCollection.AddAuthorization(options =>
{
options.AddDapr();
});
```
and then calling:

```
endpointBuilder.MapSubscribeHandler()
```

I would expect the Dapr endpoints to have the authorization "Dapr" policy applied to them (perhaps if the APP_API_TOKEN is in place, as this would indicate that I am trying to use daprs sidecar auth).

This causes conflict when I have a default Bearer AuthN and AuthZ policy applied to my endpoints; the policy I want to apply for my other controllers, like so:

```
serviceCollection.AddAuthorization(options => options.AddMainAppPermissions());

public static void AddMainAppPermissions(this AuthorizationOptions options)
{
var apiDefaultAuthPolicy = new AuthorizationPolicyBuilder(JwtBearerDefaults.AuthenticationScheme)
.RequireAuthenticatedUser()
.AddRequirements(new HasPermissionRequirement(Permissions.MainAppAccess))
.Build();

options.DefaultPolicy = apiDefaultAuthPolicy;
options.FallbackPolicy = apiDefaultAuthPolicy;
```

this is called just before the Dapr AuthZ and AuthN in Startup:

What I observed is the Dapr user is authenticated (although I have observed it not being authenticated), but then falling into the default authPolicy (as I have set it with `options.DefaultPolicy`);

obviously I cant remove this default policy, as it would mean altering the entire applications permissions for our pubsub component.

I can add:

` endpointBuilder.MapSubscribeHandler()
.RequireAuthorization("Dapr");
`
which will cause the `dapr/subscribe` endpoint to use the policy and authenticate and authorize properly. This will still cause the `dapr/config` endpoint to fail authorization.

I also decorate my controllers that are dapr topic endpoints with ` [Authorize("Dapr")]`

Additionally, the default "Dapr" auth policy could be exposed by the .NET SDK so that it can be used by the main application.

## API Versioning

Another issue is that when dapr tries to execute the mapped endpoint discovered off `/dapr/subscribe`, it wont include API versioning, which causes the app to log this error:
```
HTTP POST /main-app-entity-updated responded 200 in 437.8232 ms
[10:12:37 INF] │ Request finished HTTP/1.1 POST https://127.0.0.1:443/main-app-entity-updated - 200 0 null 473.9029ms
[10:12:37 INF] ├ HTTP POST /main-app-entity-updated (475.889 ms)
[10:12:37 INF] │ Request did not specify a service API version, but multiple candidate actions were found. Candidate actions: MainApp.Events.StateStoreEventSubscriber.SectionChangedEventHandler
```
I assume it is trying to auth against the fallback policy.

I have two work arounds for this currently; either removing the `[ApiController]` attribute and making it a `[Controller]`, or adding ` [ApiVersionNeutral]`. It would be helpful if there was a way to specify in the dapr sidecar config to dispatch requests with api versioning (ideally in different formats: URL segment, query param, headers etc), however I understand you have a policy of not adapting the runtime to benefit certain implementations, which that may fall under.

This issue seems relevant https://github.com/dapr/dotnet-sdk/issues/977

I did a pretty in-depth look at the docs and SDK source to find answers to my question (hence the default Dapr policy suggestion), but apologies if I've missed something.