Improve error handling handling in non-interactive case

[chadwhitacre]

With #1679 we provide a sub-par experience in the non-interactive case. We do want to interrupt people and force them to choose yes or no for error handling, but we should notice when they're non-interactive and give them a more helpful error message vs. blocking forever (until reaped) on the y or n prompt.

[Dherlou]

Mentioned patch made our CI/CD-Pipeline got stuck and the corresponding job to run 'forever' as well. Took a while to figure out why, because I did not expect a prompt to appear when using a --skip-user-prompt-flag.
It is a good idea to remove the blocking, but why should this result in an error message? This seems to me like an opt-in feature from data privacy perspective, so why not take no as the default value and continue with that when running in interactive mode?

[chadwhitacre]

I did not expect a prompt to appear when using a --skip-user-prompt-flag

That's fair. The "user" in this flag refers to the initial Sentry user, but I can see how it would seem to refer to the interactive user, i.e., yourself. :) Naming is hard ... kind of unfortunate for us here. 🤔

why not take no as the default value and continue with that when running in interactive mode?

If we do that, it seems highly likely that most people will never notice, and we will get only the smallest trickle of errors reported. That said, I do think we need to take a more thoughtful approach here, and fast, with 22.9.0 shipping tomorrow. Let's pick up over on getsentry/team-ospo#36 ...

[chadwhitacre]

Actually let's move to #1695 instead ...

[chadwhitacre]

I did not expect a prompt to appear when using a --skip-user-prompt-flag

#1696 for this.