Fix issubclass for Protocol with overloaded methods

[eganjs]

Description

Where Protocols are defined with overloaded methods, mypy errors with the message:

...: error: Only protocols that don't have non-method members can be used with issubclass()
...: note: Protocol "<Protocol>" has non-method member(s): <overloaded methods>

See here for an example of the failure:
https://mypy-play.net/?mypy=latest&python=3.10&flags=strict&gist=2d01059b170f6d4c66e8b0af239d5e77

This PR attempts to fix this, by checking explicitly for overloaded methods when checking for compatibility with issubclass

Test Plan

I have added this additional test:

[case testProtocolWithOverloadUsableWithIsSubclass]
from typing import Protocol, runtime_checkable, Union, Type, overload
@runtime_checkable
class P(Protocol):
    @overload
    def meth(self, x: str) -> int: ...
    @overload
    def meth(self, x: int) -> str: ...
@runtime_checkable
class PBad(Protocol):
    x: str

class C:
    x: str
    @overload
    def meth(self, x: str) -> int: ...
    @overload
    def meth(self, x: int) -> str: ...
    def meth(self, x: Union[str, int]) -> Union[int, str]:
        pass

class E: pass

cls: Type[Union[C, E]]
issubclass(cls, PBad)  # E: Only protocols that don't have non-method members can be used with issubclass() \
                       # N: Protocol "PBad" has non-method member(s): x
if issubclass(cls, P):
    reveal_type(cls)  # N: Revealed type is "Type[__main__.C]"
else:
    reveal_type(cls)  # N: Revealed type is "Type[__main__.E]"

[hauntsaninja]

In general, order of overloads matters (think multiple inheritance, or an overload that shadows another one). I think I'd just check that the overloads match exactly, allowing for more items at the end of right. Happily, this would also mean that the check would no longer be quadratic.

[eganjs]

I do not understand why the order of overloads should matter (I'm not aware of other languages where the overloads have order), and I think enforcing them to overlap exactly would be restrictive.

To expand on my thoughts, I think it would restrict otherwise valid structural typing, for example this case (mypy-play example). I might be getting my terminology wrong, but I think this is an example of contravariance, which I think is something that should be permissible with overloads, as it is with other methods on a protocol (mypy-play example). This example is valid under the initial implementation and I do not think it would be if the check was re-implemented the way you have described (perhaps I am wrong here?).

[eganjs]

@hauntsaninja could you please respond and expand more on the reasoning behind what you've said?

[eganjs]

@JukkaL would it be possible to get a second opinion on this?

[hauntsaninja]

Thank you for making this PR! #9904 fixed the protocol typing that this PR fixes and various changes on master replaced the overload logic here with existing overload logic that handles order correctly. The mypy-play links here all pass with latest mypy (although there's still at least one bug, fixing in #14018 )

[eganjs]

I'm glad to see this is now resolved, it's unfortunate that the lack of dialogue resulted in delaying a resolution from being merged for so long.