Document which PubSub providers support multiple subscriptions to same topic #4960
Description
What content needs to be created or modified?
The documentation for providing a route for Dapr to discover topic subscriptions doesn't suggest that there's a limitation one way or another on how many subscriptions might be set up for a given component and topic.
The .NET SDK historically limits this to one subscription at a time - attempting to register more than one using the same values overwrites the previous one.
Talking with @JoshVanL about it today on Discord, it sounds like each registration would get a subscription on the backend, but that whether it would work or not would depend on each PubSub provider.
There's a PR open in the .NET SDK to change the SDK behavior and allow named subscriptions that would allow multiple inbound discoverable routes for the same component and topic overriding the previous behavior. I'm hesitant to add it since it's not clear that this is supported behavior on the runtime and because the SDK only does limited component integration testing (entirely against Redis for pubsub, I believe), so I have no visibility into which components this would or wouldn't work for.
Describe the solution you'd like
Could you please draft some documentation somewhere that I can point to from the SDK documentation that clearly illustrates which PubSub providers would support this or not (presumably inferred from component certification testing, if they even attempt this sort of test) so this PR might be merged?
Where should the new material be placed?
Ideally this section would be updated to clarify that multiple routes to the same component/topic are supported.
Further, a table which PubSub providers support this would probably be best placed in the PubSub broker documentation, perhaps like we list the optional interface support for state providers?
The associated pull request from dapr/dapr, dapr/components-contrib, or other Dapr code repos
dapr/dotnet-sdk#1657
Additional context