Feature (WIP): Add support for default account override

[kemmerle]

Description and Context

Relies on HubSpot/hubspot-local-dev-lib#228

In this PR, I'm implementing support for default account overrides with the new centralized configuration file.

Now, customers can place a .hs-account file in any directory where they would like the default account overridden. The .hs-account file will contain a single numerical entry: 1234567, or the account ID. Any changes made in the directory and its subdirectories will apply in the account stipulated in the .hs-account file. This will work very similarly to our nest configs currently do.

The advantages are:

1. We will still have one centralized configuration file and therefore one single source of truth.
2. We will create a command to auto-generate the .hs-account file, so that customers need never have to manually interact with the config.
3. It's much more secure, if a customer accidentally uploads the file to GitHub--it contains no sensitive information besides an account ID.

TODO

• Implement the hs accounts create-override command
• Address feedback

Who to Notify

@brandenrodgers @camden11 @joe-yeager

[brandenrodgers]

I'm realizing the implication of getAccountId potentially throwing an error. Before, the worst case scenario was that getAccountId could return null, but now it can throw an error. Does that mean we have to go through every usage of it in the app and wrap them all in try/catch blocks? I wonder if there's some way to get around having to do that 🤔

Is it safe to just make the assumption that any potential thrown errors from getAccountId() would get caught here in the middleware, before any of the code in the commands can execute?

[kemmerle]

Yes, we can safely assume that any potential errors from getAccountId() will be caught in injectAccountIdMiddleware.

Apart from the init and auth commands, injectAccountMiddleware will run in the middleware before every command handler. Actually, the work you did to eliminate multiple getAccountId functions guarantees that--now we call the same function every time, so we know that if it fails in the command, it will also fail in middleware.

[brandenrodgers]

Looks like a copy/paste leftover here 😄

[kemmerle]

Not quite sure what you mean--I based the type off of the types in the hs account info command but had to make some changes. Should I move this to Types, so we can reuse between commands?