PDE-5319 feat(cli): invoke auth start subcommand

[eliangcs]

Changes:

• add zapier invoke auth start subcommand
• add support for --non-interactive flag to zapier invoke command
• document zapier invoke better
• remove Node.js 16 from CI tests and add Node.js 20
  • did it because the open package added in this PR requires Node.js 18
  • had to upgrade mock-fs along the way because the old version wasn't working on Node.js 20 😠

The auth start subcommand works with the following authentication types:

• oauth2
• basic
• custom
• session

Authentication types oauth1 and digest are rare, so I'm leaving them out of this PR for now.

For oauth2, auth start does following:

1. Check if CLIENT_ID and CLIENT_SECRET are defined in .env. If not, prompt for them.
2. Start a local HTTP server waiting for the redirect request
3. Open the browser with authentication.oauth2Config.authorizeUrl
4. Get the code parameter in the redirect request and call authentication.oauth2Config.getAccessToken to get the access token
5. Save the access token to .env

For basic and custom, auth start simply prompts for the auth fields.

For session, auth start prompts for the required auth fields and calls authentication.sessionConfig.perform to get the computed auth field(s) (e.g. a session key).

[standielpls]

I tested custom and oauth2, and they work! Nice job! Excited for this.
I have a pair of non-blocking comments

[standielpls]

Why does basic auth need interactive mode?
Is it for censoring the password?

[eliangcs]

Basically we want to make sure the CLI doesn't ask interactive questions in non-interactive mode (nonInteractive === true). For basic auth, the only thing that auth start does is ask for username and password interactively. auth start with basic auth doesn't really make sense in non-interactive mode, which is why we throw an error here.

Does that make sense?

[eliangcs]

In case you're asking why we're not allowing this non-interactive use case for basic auth:

echo '{"username":"user","password":"secret"}' | zapier invoke auth start

We could but I thought that would be useless, since it'd be easier for the user to edit .env or append the auth fields to .env:

echo 'authData_username=user' >> .env
echo 'authData_password=secret' >> .env

[standielpls]

I got stuck at authorizing bc of bad params, I reckon it's hard to kill this process if the browser request errors?
Do you think it's valuable to set a timer for the code promise or provide 'ctrl/cmd + c' to abort helper?

[eliangcs]

If the partner server encounters an error and doesn't redirect to localhost, we won’t be able to detect the error. I prefer not to use a timer for this. I think the best approach would be to let the user know they can press CTRL-C to exit if an error occurs. I've added this in 9929e9c.

CTRL-C already works on my machine. Does it work on yours? @standielpls

[standielpls]

Yes it does, thank you for adding the hint text