improves error messages for better error logging/troubleshooting

[tonytheleg]

PR Template:

Describe your changes

The goal of this PR is to update any error messages/logs where the issue may not be clear what failed. That includes:

• Methods that have multiple error checks -- each error returned now at least explains what failed
• Methods that don't return errors but have error checks, errors are now logged to know what failed
• Any instantiation that may call external packages where the error is clear but the reason its being called is not.

These should all loop back to a logger as it bubbles up, which will ensure any error logs can be easily correlated to some code logic hopefully and make troubleshooting easier

Ticket reference (if applicable)

For RHCLOUD-35835

Checklist

• Are the agreed upon acceptance criteria fulfilled?

• Was the 4-eye-principle applied? (async PR review, pairing, ensembling)

• Do your changes have passing automated tests and sufficient observability?

• Are the work steps you introduced repeatable by others, either through automation or documentation?

  • If automation is possible but not done due to other constraints, a ticket to the tech debt sprint is added
  • An SOP (Standard Operating Procedure) was created

• The Changes were automatically built, tested, and - if needed, behind a feature flag - deployed to our production environment. (Please check this when the new deployment is done and you could verify it.)

• Are the agreed upon coding/architectural practices applied?

• Are security needs fullfilled? (e.g. no internal URL)

• Is the corresponding Ticket in the right state? (should be on "review" now, put to done when this change made it to production)

• For changes to the public API / code dependencies: Was the whole team (or a sufficient amount of ppl) able to review?

[josejulio]

lgtm