Re-do --confirm flag related interaction behavior

[JoeHCQ1]

Is your feature request related to a problem? Please describe.

As a Zarf user for the last six months, I am slowed daily by the --confirm requirement for some commands.

I believe the intent was to help people avoid accidentally deleting a package similar to how GitHub, for example, requires you to type the org and name of the repo you want to delete into the delete dialog. However, this doesn't actually do that because I can add the --confirm flag without ever re-reading my command.

As a technical user, I don't think it's helpful to check that I meant what I said if I type zarf remove package gitlab. Poor cost/benefit ratio.

As a non-technical user, I'm probably copying and pasting commands anyway. So, if the --confirm flag was included in the docs/script then there's no value added. If it was not, as a non-technical user, I may be at a bit of a loss to resolve the situation. Tools from unfamiliar domains can be surprisingly opaque no matter how clear the commands or logs involved. This interactivity may only serve to increase complexity.

As an experienced Linux user, this --confirm interactivity is unusual compared to the rest of the Unix ecosystem. Typically this would be either a -f/--force or -y/--yes flag. Also, if those flags are missing, typically the tool will prompt for it like with Apt's [y/N] to continue prompt. Even so, in case of an apt install <pkg>, apt doesn't ask you if you meant to install the pkg, it tells you more information about what that command entails, and then asks you to confirm you want to proceed in light of new information. Zarf isn't providing new information about what the command will do, although that would be helpful.

Describe the behavior you'd like

1. Replace --confirm with -y/--yes where the behavior is retained.
2. Remove --confirm behavior from commands where all information is already present in the initial command.
3. Where --confirm interaction is preserved, provide new information to the user about what the command will do before prompting for a confirmation and make that confirmation UNIX typical in it's behavior (bypass with -y or -f if more appropriate, prompt after giving user more context via [y/[N] prompt.)
4. Do not break backwards compatibility. Translate the --confirm flag if provided into --yes and print out a log warning that --confirm is deprecated.

I'd suggest the -f/--force flag would be more appropriate to use when say overriding a the resource conflict that comes to exist when a resource already exist and the annotations say it belongs to a different Zarf package. -f is how I'd force adopt those resources, or force deploy when another upgrade is in process, etc. So, the existing --confirm behavior is probably better suited to the -y/--yes flag.

Background Context

From discussion with early Zarf developers / those who were nearby as it was built:

[T]he original thought was that it might be easy to accidentally click y when the confirm prompt occurred (such as seeing a confirmation prompt without reading what you are confirming). Requiring someone to manually type out the word --confirm [is intended to make] it more likely that an accidental removal [doesn't] happen.

The original User Persona we were targeting with Zarf was someone who was not technical at all. Because of this, we tried to build "guard rails" like this in a few places.

[JoeHCQ1]

I like the way GitLab's DB drop Rake tasks does it:

gitlab-rake db:drop
rake aborted!
ActiveRecord::ProtectedEnvironmentError: You are attempting to run a destructive action against your 'production' database.
If you are sure you want to continue, run the same command with the environment variable:
DISABLE_DATABASE_ENVIRONMENT_CHECK=1
/srv/gitlab/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.8.4/lib/active_record/tasks/database_tasks.rb:69:in `check_protected_environments!'
/srv/gitlab/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.8.4/lib/active_record/railties/databases.rake:18:in `block (2 levels) in <main>'
/srv/gitlab/vendor/bundle/ruby/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/srv/gitlab/bin/bundle:5:in `load'
/srv/gitlab/bin/bundle:5:in `<main>'
Tasks: TOP => db:drop => db:check_protected_environments
(See full trace by running task with --trace)