fix: Referencer, Name conflicts, Mapped unions, etc.

[nemnandor]

All Submissions:

• [X] Have you followed the guidelines in our Contributing document?
• [X] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [X] 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)?
• [X] This PR is associated with an existing issue?

Closing issues

closes #477 closes #623 closes #681 closes #1191 closes #1204 closes #1266 closes #1447 closes #1472

If this is a new feature submission:

• [ ] Has the issue had a maintainer respond to the issue and clarify that the feature is something that aligns with the goals and philosophy of the project?

Fixes:

I have solved locally some problems which are needed for my company. After that I read the TSOA commit guides, so some fixes maybe have no related issues.

1. Namespaces: Every type should be stored with their full-path namespaced types. Even if the source code not uses this name. This reduces conflicts between types.
2. Name conflicts: If every reference type name parts are uniq, then the full type name can be handled as uniq. In this type name, we need to sign the jsdoc params if exists, because its they can make differences in the result. Somehow the reference type names are transformed with an irreversible getRefTypeName(), here we need to check if the result name comes from the same original type names, or from more different names.
3. Handling interfaces - namespaces - enums which have more than one declaration
4. Keep jsdoc comments + defaults after mapping - as intellisense shows
5. Do not use original definition in mapped types, because type can change.
6. Accept unions, intersections, nulls, enums in mapped type.
7. Fix referencer issues. TypeToTypeNode & TypeNodeToType functions are not exactly the inverse function of each other -> use the original types, and remove conversions.
8. Do not name more complicated reference type internal parts as "any". - It is needed to recognize name conflicts.
9. Better keyof handling
10. Do not mark required if a field has a default value. (Not too relevant, but more beautiful)
11. Default values from JSdoc uses the expected type. @default true is not a string, but a boolean.

Potential Problems With The Approach

• My code sometimes returns with an equivalent type definition, not the original (If #1490 is a bug, then I made bugs). Check original test changes.
• I have not implemented Partial or Partial-like mapped types. I can implement it, but not really know if it is interesting or not/where is the end of this strange types.
• I solved name conflict handling, but for it I generate the type name every time (previously tsoa made it in the else branch, but normally we used the typescript name). For some name, some type formations are not implemented, like: type A = Partial<{ [a in keyof B]: string }> But there is a workaround: type AInternal = { [a in keyof B]: string }; type A = Partial<AInternal>
• A mapped type can change the type of a member, but can not change the jsdoc of it (sometimes deletes it, but sometimes not). So we can create a number member (with default value 2, and minimum 0), and after that, we can construct a mapped type which can change the type to string. Everything is fine with intellisense, but we can define a type which should have a value, because if not, the default value will have another type, so typecheck fails. Now TSOA handles type restrictions which are related only to one type, so in this case there will be not relevant type checks, not really interesting.
• If a type (interface) has multiple declaration, and both declarations contains the same member with different jsdoc, the program chooses one of them.
• Union types in typescript are a little bit strange, A | B ~ { some properties of A & some properties of B}. TSOA validation not handles them correctly (TSOA validation implementation: A | B = Only A | Only B). In a type with multiple different additionalProperties type I use type unions to "approxximate" the expected operation. It is ok until someone fixes TSOA validation. But I'm not sure, that most programmers love or hate this TSOA validation bug, I enjoy it, it is more strict than ts.

I'm sure, that there are a lot of breaking changes.

Test plan

Added test type literals to the TestModel interface. Every literal checks one solved problem. The members represents one test case.

[WoH]

Can you take a look at CI? Let's start there.

[WoH]

LGTM, thanks for the PR and sorry for the time it took to review.