[red-knot] Infer the members of a protocol class

[AlexWaygood]

Summary

This PR adds the necessary machinery to infer the members of a protocol class, and uses that machinery to infer a precise return type for the get_protocol_members introspection function.

What this PR doesn't do is infer what the type of each protocol member is. We'll obviously have to do that in due course to properly implement protocol subtyping and assignability; when we add that functionality, I'm envisaging that ProtocolClassLiteral::members() would return a HashMap mapping from the member to its type rather than a boxed slice of Names. I'm deliberately not doing that right now, however, as implementing all the subtyping rules around protocols is a somewhat large task, which I intend to approach incrementally over several PRs. The first stage will possibly not even consider the types of the protocol members at all.

Test Plan

Existing mdtests updated.

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

[carljm]

Keep in mind (both in terms of method naming, and where you put what functionality) that autocomplete is definitely going to require the ability for ClassLiteralType itself to have a "list all members" method. And if ProtocolClassLiteral will be used inside a future Type::ProtocolInstance, it will probably also need to expose that list-all-members method, without all the Protocol-specific filtering. That could suggest some future refactoring to share some aspects of list-members functionality, but more concretely I think it suggests that we should reserve the method name members for the general "list all known members" that all types will need, and use something like protocol_members to distinguish this protocol-specific method.

[AlexWaygood]

autocomplete

for some reason it took me a moment there to realise that you mean "the autocompletion feature we intend to build into the red-knot LSP for IDE users" rather than "autocompletion in the IDE now for red-knot developers" 😆

That could suggest some future refactoring to share some aspects of list-members functionality, but more concretely I think it suggests that we should reserve the method name members for the general "list all known members" that all types will need, and use something like protocol_members to distinguish this protocol-specific method.

Interesting -- I think they will end up doing nearly the same thing. I suppose the only difference between them really is that the members method I'm adding here (which I'll rename to protocol_members) should not include implicit instance attributes (these are illegal in protocol classes, and do not constitute protocol members). But the autocomplete feature probably should include those members:

class Foo(Protocol):
    x: int

    def __init__(self):
        self.y = 42  # we should emit an error here,
                     # and not infer `Foo` as having a protocol member `y`
                     # (it should only have a single member, `x`)

[carljm]

Right, makes sense. It seems like also the filtering-out of some "special" names is something we might not want to do for autocomplete?

[AlexWaygood]

in due course this will need to be converted to a HashMap of some kind where the keys are the names of the protocol members and the values are the types of the protocol members. But I don't want to do that yet because I'm not yet sure whether e.g. an attribute member annotated with Callable should be treated the same as a method member (I need to write some more tests...)

[carljm]

Looks great!