QC: Eliminate use of cli_alert_*()

[jonthegeek]

QC Details

I finally found confirmation that cli_alert_*() functions are leftovers from an older way of doing things in {cli}. Per that ticket:

• [ ] "cli_alert_danger" = "use cli::cli_inform()" (but I'd guess we probably actually mean cli_abort() or cli_warn())
• [ ] "cli_alert_info" = "use cli::cli_inform()"
• [ ] "cli_alert_success" = "use cli::cli_inform()"
• [ ] "cli_alert_warning" = "use cli::cli_inform()" (but I assume we actually mean cli_warn())

The main issue I've found is that cli_alert_warning() doesn't actually count as a warning for testing; it's just a message dressed up as a warning. Not a HUGE issue but can make things confusing.

Additional Comments

[jonthegeek]

Hmm, I'm not sure this is quite right. BUT we should be cautious about cli_alert_*() usage.

• Use cli_alert_*() only as fancy versions of message() or cli_inform().
• If we want it to register as a warning (or stop as an error), we must use cli_warn() and cli_abort().

I think we can gather intent by whether something returns, whether that thing is the expected return, and the tone of the message, but we should check one by one.

[jwildfire]

Makes sense to me to tighten this up. Let's address in v2.1 or v2.2. We may also want to do a more through review of our logging as we move more runs in to GHA.

[lauramaxwell]

Based on discussion in #1814 , we should replace cli_alert_danger() with cli_abort() in most cases so that we don't continue in a pipeline that has failed validation-type checks.