Speed up type checking by explicitly annotating some type parameter variances

[akaltar]

Why

In certain cases, type inference could be slow and reach typescript depth limits. Eg #3214

How

By using typescript performance tracing on some examples from the above issue, I've manged to track down the slowness to checking the variances of various type parameters.
I used TypeSlayer's Type search to find the types where the variance was checked, and using the result data from the performance trace, I filled in the variances.

Since not all types of variance can be marked explicitly, I skipped some of them or added a different specifier. Eg in for bivariant.
I'm not 100% sure if this is correct, but many combinations produced type errors in various places, so based on my current understanding a wrong variance would cause type errors elsewhere.
I'm also not sure if this catches all common occurrences of this issue as I was using very simple examples. I will test for robustness + effectiveness by running the changes through a proprietary project and reporting the results.

I'm also not sure if this is the ideal way to solve this problem, I'd assume that there are other simplifications one could make to the types that would result in the built-in variance checking to get faster, but I couldn't find those and don't know enough about what's slow in the current version to do that

I think this could be a breaking change for some users:

• in some cases the reduced type complexity will surface existing type issues that were too complex to discover before
• In some cases the variants might cause a different breakage in client code => I'm hoping that the tests sufficiently account for this

What

• Change EndpointBuilder from a type alias to an interface
• Add in out or in out variance specifiers to some type properties

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit be7b4c6:

Sandbox	Source
@examples-query-react/basic	Configuration
@examples-query-react/advanced	Configuration
@examples-action-listener/counter	Configuration
rtk-esm-cra	Configuration

[netlify]

✅ Deploy Preview for redux-starter-kit-docs ready!

Name	Link
🔨 Latest commit	be7b4c6
🔍 Latest deploy log	https://app.netlify.com/projects/redux-starter-kit-docs/deploys/69450a87da8cf4000828a120
😎 Deploy Preview	https://deploy-preview-5168--redux-starter-kit-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[markerikson]

.... huh. wow.

this is already clearly over my head :)

First question is what this does to our existing type-tests, then we can go from there.

Either way, though: regardless of whether this works or not and whether we merge it, thank you for putting in serious investigation time, trying to optimize perf here, and filing this PR!

[markerikson]

well nothing obviously broke :) that's either a very good sign, or a sign that we're not testing things sufficiently :)

@akaltar can you use the PR build to do some revised perf comparisons?

Also, I'd love to see before and after flamegraphs!