Consider automatically hiding protocol methods when there is a convenience overload

[JoshLove-msft]

The recommendation from .NET architects is to hide protocol methods via EBN if there is a corresponding convenience method. Ideally, this would be enforced by the generator so that devs don't have to remember to do this for each library.

[JoshLove-msft]

Related docs issue - Azure/azure-sdk-for-net#43627

[ArcturusZhang]

Since we have different method patterns on non-azure libraries, does this also apply to non-azure libraries?
Non-azure libraries do not have cancellationToken in their convenience methods, and it is required to use the corresponding convenience method when they need cancellation context in their invocation, would it be appropriate to hide the protocol methods there?

[lirenhe]

@JoshLove-msft, as you mentioned this idea is coming from .NET architects, do you have any meeting notes that you could share?
I would like to know more context about this decision.

cc @m-nash

[JoshLove-msft]

@JoshLove-msft, as you mentioned this idea is coming from .NET architects, do you have any meeting notes that you could share?
I would like to know more context about this decision.

This was from an informal discussion with @KrzysztofCwalina and @tg-msft regarding the new Event Grid library.

[KrzysztofCwalina]

The context is that we keep seeing in UX studies that once convenience overloads are added, users have a hard time deciding which overload to use.