chore(typescript): bump tsc globally and switch to nodenext for iroha2

[aldousalvarez]

Here are all the changes implemented for
moduleResolution to nodeNext and Typescript upgrade

1. Upgraded TypeScript to 4.7.4 globally and switched
   moduleResolution nodeNext in cactus-plugin-ledger-connector-iroha2
2. Upgraded @typescript-eslint/eslint-plugin &
   @typescript-eslint/eslint/parser to 5.27.0
   so that it supports the newer version of Typescript.
3. Added useUnknownInCatchVariables: false in tsconfig
   and tsconfig.base.json to fix the errors related to
   'unknown' type in catch variables that occurred after
   upgrading the typescript.
4. Updated rxjs to v7.8.1 globally in all package.json files
   to match the version in IrohaV2. This is better than adding a resolution
   in the root package.json because it makes it visible and explicit that
   we've upgraded the dependency everywhere. The global resolutions
   override is a last resort option because it is pretty confusing to
   beginners when they specify a dependency version in their own package.json
   but it doesn't ever get installed because of the override coming from the
   top level package.json.
   The reason the upgrade was needed to begin with: Typescript compiler
   errors were being caused by the mismatching version of rxjs that the
   iroha2 client packages depend on vs. the versions that our codebase
   uses. Now with the upgrade they are in sync and the build passes.

---

Secondary change:
Peter: I'm sneaking in another hot-fix for the codegen task which makes
the .jar download (that's part of the warmup script) SEQUENTIAL instead
of having it PARALLEL which appeared to be working fine earlier but it
no longer seems to be the case, e.g., I've seen some race condition
looking errors pop up after having merged the PR with the earlier hotfix.
The root cause of the issue likely the openapi-generator-cli package
itself not being safe for concurrent use in general, but a full audit of
that code would have to be performed to validate this theory. For now
it is just easier to set it to SEQUENTIAL and be done with it (hopefully)

Fixes #2158

Co-authored-by: Peter Somogyvari [email protected]

Signed-off-by: aldousalvarez [email protected]
Signed-off-by: Peter Somogyvari [email protected]

[gitguardian]

️✅ There are no secrets present in this pull request anymore.

If these secrets were true positive and are still valid, we highly recommend you to revoke them.
Once a secret has been leaked into a git repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.

---

<sup><sub>🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

Our GitHub checks need improvements? Share your feedbacks!</sub></sup>

[jagpreetsinghsasan]

LGTM, just fix the PR commit message.
You can refer to this: 57eb605 (#2207)

[petermetz]

@aldousalvarez This is a great work, but I'd strongly prefer breaking it down to multiple smaller pull requests which are all focused on changing a single thing (for example one pull request that does nothing but upgrading to Typescript 4.7.x)

But, before we even get to that, here's another question for me to get more context: It looks to me like we could do the change to moduleResolution on a per-package basis (once the compiler is up on >=v4.7.x) therefore we could limit the scope of this PR to a much smaller scale that does nothing but exactly satisfying the requirement from @outSH which is that in a specific package he'd like to use a dependency that requires the new module resolution mechanism.

So, the question: Could we break this whole work down in this way:

1. The compiler upgrade to >v4.7
2. PR that switches only the specific iroha connector package to moduleResolution nodenext
3. N number of PRs later on that can change more packages to the new module resolution over time - thus breaking this giant diff down to smaller, digestible chunks?

Also note (to myself mostly) that we want the flag turned on in the future that forces developers to deal with the runtime type of the thrown exceptions (which is something that Typescript 4.4 introduced as a feature that we - me at least - very much want enabled in our codebase)

[aldousalvarez]

Hello @petermetz here is the updated commit with moduleResolution to nodenext and typescript upgrade to 4.7.4 is only on iroha2 connector

[petermetz]

Hello @petermetz here is the updated commit with moduleResolution to nodenext and typescript upgrade to 4.7.4 is only on iroha2 connector

@aldousalvarez You upgrade the compiler to v4.7 project wide not just for the package but that's okay because this is the only way to do it anyway. I meant to send that in a separate PR, but the diff is not that large now that you cut down on the rest of the packages so I'm just gonna let it go because the CI is way too slow right now so I'm trying to be a little less nit-picky about mixing different commits into a single PR.

[petermetz]

@aldousalvarez Please explain in the commit message the reason behind each change.
Your point 4 explains why it was done but 1,2,3 just says "this is what I did" but not "why".

If someone comes back to this later because we broke something else that we didn't realize at the time, they have to be able to figure out why we made the changes we made so that they can make better/more educated decisions about what the fix might be (and ideally they need to be able to do that without having to have a discussion about it with you or me)

Other than that, the PR diff itself is LGTM, thank you!

[aldousalvarez]

Hello @petermetz already updated the commit message and I have explained there why I did those changes. Thank you

[petermetz]

@aldousalvarez LGTM now, but I've made some changes:

1. Instead of a global resolution I've upgrade rxjs explicitly via the dependency declarations. Same end result but less confusion. I further explained this in the commit message. The diff is much larger this way but much easier to understand/reason about it and so it's less technical debt (IMO).
2. I snuck in yet another hot-fix for the codegen script which is still suffering from concurrency issues.

@jagpreetsinghsasan @takeutak @izuru0 @VRamakrishna @sandeepnRES Please re-review with the above change in mind.

[izuru0]

LGTM