Add support for typeof keyword in type parameters

[pclements12]

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you written unit tests?
• Have you written unit tests that cover the negative cases (i.e.: if bad data is submitted, does the library respond properly)?
• This PR is associated with an existing issue? Support zod's infer type #1256

References Issue

This attempts to fix at least one of the sub issues related to the ability to use Zod's z.infer that was identified in #1256
#1256 (comment)

1. Typeof Name Calculation Issue
   Error message: No matching model found for referenced type value.

@Route("/test")
export class TSOATestController extends Controller {
  @Get("/")
  async test(): Promise<ValueType> {
    return null as unknown as ValueType;
  }
}

const value = null;

type Infer<T> = T;

type ValueType = Infer<typeof value>;

The issue is that when calcTypeName runs for a typeof operator type (a TypeQueryNode), it calls calcRefTypeName on the operand. The doc comment and code for calcRefTypeName indicate it only accepts a reference to a type. The obvious problem here is that the operand of typeof is never going to reference a type. The typescript typeof operator only accepts references to javascript variables, functions, etc. – i.e., non-types.

Thus, the call to this.calcRefTypeName(arg.exprName) is simply wrong, and is an outright bug that needs to be fixed.

Test plan

Adds a test case to the metadata / parameter resolver for typeof types as a parameter or return type

Adds an (expensive) unit test for TypeResolver to explicitly enumerate all of the type combinations that the resolver supports in a clean room environment. Open to suggestions on making this more efficient by combining into a single virtual source file, but the context of type right next to test is very valuable imo.

I've also included some types in this test that still fail (currently skipped) and are related to the other issues identified in #1256

[pclements12]

@WoH can you take a look at this when you get a chance?

[WoH]

I'll get to it over the weekend!

It looks good from slimming the code, but I'll try to play around with it a bit

[WoH]

I'd prefer if you could integrate the tests in this file with the existing tests

[WoH]

Spec Generators Tests most likely

[pclements12]

This isn't really about spec-generation though. These tests are about type resolution. The spec generation tests are relevant after a type has already been resolved. None of them use the type resolver.

Currently the testing for type resolution is spread across the controller/method/parameter generator specs, but those are higher order integration tests than what I'm testing here.
If we were going to merge them with existing tests, it would be somewhere in those.

In my opinion the lack of easy testability for type resolutions is one of the reasons that there are quite a few type resolution bugs outstanding for the repo. This test may make it easier for folks to identify and fix those in a much more narrow focus area.

[WoH]

A lot of the property management should already exist in checker based resolutions.

Ideally we can merge them together.

[pclements12]

Can you elaborate on what you mean? Do you mean putting this code in a location that can be shared across other places where we do property management in this file?