[TypeScript-Consolidated] Fixes invalid type enum array & incorrect discriminator value if mapping is present

[TiFu]

See #14892

Still WIP - will expand on description once ready.

@wtrocki Code now compiles for the spec that you had posted; Will have CI run the tests against the existing specs in OpenAPI Generator to see whether I broke anything else.

CC Technical Committee
@TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx @macjohnny @topce @akehir @petejohansonxo @amakhrov @davidgamero @mkusaka

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  For Windows users, please run the script in Git BASH.
• In case you are adding a new generator, run the following additional script :

  ./bin/utils/ensure-up-to-date.sh
  

  Commit all changed files.
• File the PR against the correct branch: master (6.3.0) (minor release - breaking changes with fallbacks), 7.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[TiFu]

TODO: Extract to AbstractTSClientCodegen

[wtrocki]

*key*

can be constant with PLACEHOLDER name.

#PLACEHOLDER# or something else.

[wtrocki]

Actually using regular expression with replaceAll might help avoiding placeholder. We always looking to replace last occurence

[TiFu]

Is it always the last occurrence?

Wondering whether there are more complicated examples where this does not hold - mainly thinking about cases where the same type appears twice (e.g., Tuple<string, string> to Tuple<FancyEnum, FancyEnum>).

In cases like this, our model is anyway broken because we lose type information when generating the initial type.

[wtrocki]

Precompiled. It does solve the issue with array.

[TiFu]

Technical committee: Would appreciate your review/input :)

@TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx @macjohnny @topce @akehir @petejohansonxo @amakhrov @davidgamero @mkusaka

[bodograumann]

Sounds like maybe a unit test makes sense here!?
That would also help me better understand the issue here.

I would definitely prefer a proper fix when generating the type instead of a workaround with string replacements.

[TiFu]

Agreed, let me add some unit test.

If I remember well (few weeks ago when I worked on this), I initially tried going for a proper fix but discovered that the function where the initial type is set does not have the full context necessary to set the right type from the start
Let me have another look at this and provide a bit more data-based rationale :)