Introduce a helper function to map types to protocols + fix for dict kwargs false positive

[randolf-scholz]

Fixes: #20424

Following my comments in #20416, this PR introduces a new helper function as_type that can be used to determine whether a type can be matched to a certain protocol or not.

As an example application, I fix a bug in is_valid_keyword_var_arg that stems from checking

kwargs <: SupportsKeyAndGetItem[str, Any]

This check is too eager, because SupportsKeyAndGetItem is invariant in the key type, it will produce a false positive when kwargs is for instance dict[Literal["foo", "bar"], int]. The correct test is:

Does there exist T <: str so that kwargs <: SupportsKeyAndGetItem[T, Any]

which can be checked with the new helper function.

Updated tests

I updated testLiteralKwargs to test:

• both good and bad dict argument
• both good and bad Mapping argument
• both good and bad SupportsKeyAndGetitem argument

[randolf-scholz]

had to put these there due to circular import issues

[ilevkivskyi]

This function should definitely not be in this module (ideally we shouldn't even have the existing typeops import below, but that is a separate story).

Also the scope of this function is misleadingly broad. It should probably accept a TypeInfo as target (which probably must be a protocol), and then use fill_typevars(...) as a constraint inference target.

Finally, it is worth doing some performance measurements, we don't want any visible slow-down for something that is only needed for rare edge cases.

[randolf-scholz]

Is it intentional that solve_constraints ignores the upper bounds of the tvars it solves for?

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅