CLI: Refactor package manager methods to be async

[yannbf]

Relates to #22343

What I did

This PR turns most of the package manager methods into async, plus updates every other place that refers to them.
It also does a small refactoring on some method signatures to make the code more readable and maintainable.

This is to prepare for other PRs which will need the async nature of the package manager proxies!

How to test

1. Tests should be green (unit + sandbox)

Checklist

• Make sure your changes are tested (stories and/or unit, integration, or end-to-end tests)
• Make sure to add/update documentation regarding your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Maintainers

• If this PR should be tested against many or all sandboxes,
  make sure to add the ci:merged or ci:daily GH label to it.
• Make sure this PR contains one of the labels below.

["cleanup", "BREAKING CHANGE", "feature request", "bug", "documentation", "maintenance", "dependencies", "other"]

[shilman]

Generally LGTM. The only questionable bit for me was changing the function signature for executeCommand from args to an options object. I could also imagine making executeCommand sync to make it backwards compatible and introducing an executeCommandAsync with the new behavior. But I consider this an internal API so the current changes seem good.

[shilman]

We could also achieve the fix in the PR without introducing any async right? So this PR is making a bunch of changes in the name of future work that we're not actually doing right now? In which case, I'd consider just doing the bare minimum instead.

[yannbf]

We could also achieve the fix in the PR without introducing any async right? So this PR is making a bunch of changes in the name of future work that we're not actually doing right now? In which case, I'd consider just doing the bare minimum instead.

This change was a request from @ndelangen as part of another PR which I'm working on. The other PR will change the way the executeCommand method behaves so that when running e.g. yarn install, no output is shown to the user, but rather it will be streamed to a log file, which will only be shown if there is an error.
To create a stream, I need to use createWriteStream, which is usable only after it emits an open event, making me need to handle it in an asynchronous nature.

In order to make that possible, there are two ways:

• Keep things non-async with no further changes needed, but introducing bad side effects and a possible race condition
• Changing things to async, and having no issues

Because making stuff async would make the first work generate an incredibly big PR (as you can see from this one), I decided to split into two PRs instead, so this one would be just a refactor rather than introduce bigger changes.

[shilman]

Gotcha. thanks for the clarification! 🙏