Version 2.0 flow & user auth

[pippinlee]

@mikemimik let's use this as a guideline for async.waterfall flow. Let me know if flow doesn't make sense. I'll also use this as a guideline to make tests.

Initial

• add “issues/“ to .gitignore if not already there
• is ./issues created if it doesn’t exist
• is remote URL found for repository

If Public repo

• doesn’t need to ask for auth
• successfully gets all open issues from github
• successfully gets all comments in open issues
• successfully console.log's all issue titles and saves each issue to ./issues

If Private repo

• check if ~/.config/get-issues/setup.json and auth token exist
• if no token locally, create one by prompting for user/pass
• after creation, is auth token saved locally to ~/.config/get-issues/setup.json on Mac
• after creation, is auth token saved locally to SOME/WINDOWNS/PATH on Windows
• if token exists, read token and use for auth
• use auth with github api to get all open issues and comments
• console.log's all issue titles and save each issue to ./issues

If private repo and 2FA required

• check if ~/.config/get-issues/setup.json and auth token exist
• if no token locally, create one by prompting for user/pass, will also need to get user's auth code via sms
• write newly created token locally
• along with Basic Auth send header with user's auth code in X-GitHub-OTP header to Github
• console.log's all issue titles and save each issue to ./issues

[mikemimik]

The "Finish up" section tasks happen in the init() function which is the first to execute in the waterfall

[mikemimik]

Also the auth process is more complicated.
Simple username/password requires one header,

2FA needs another header, and I'm not sure if the code you get with 2FA needs to be sent with it.

The header creation will need to be abstracted away from the waterfall, and the waterfall can switch-case over which header it needs to send.

The information to figure out which header is needed will only come from poking at the API and checking the error responses. There isn't a way to inherently know if an account is simple username/password or 2FA before hand, unless you work that into the user flow with inquirer.

[pippinlee]

Cool! I'd planned on getting 2FA added after we're back up and running but makes sense to include it while we're fixing up auth flow. Would be nice to have for V2.0.0 too.