Do not create conda error reports for common / expected exceptions

[jaimergp]

Description

Closes #5263

This is what we would need to close that issue without registering new base classes in conda exception handler.

CondaError calls super() so we can't compose new exception types that inherit both from CondaError and e.g. CalledProcessError. This prevents us from having a mixed exception that doesn't change which type of exception is raised (for the purpose of try/except idioms or isinstance checks).

I'd rather have this:

class BuildScriptException(CondaError, CalledProcessError):
  ...

and then call:

try:
  subprocess_for_build_script()
except CalledProcessError from exc:
  raise BuildScriptException(exc, ...) from exc

Achieving this ^ will require changes in conda/conda though (either changing the CondaError class so it doesn't call super(), or having a different base class for the purpose of exception handling like BaseCondaError).

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• Add / update outdated documentation?

[codspeed-hq]

CodSpeed Performance Report

Merging #5264 will not alter performance

_{Comparing jaimergp:error-gracefully (0f0fd8a) with main (aea5a22)}

Summary

✅ 3 untouched benchmarks

[jaimergp]

pre-commit.ci autofix

[jezdez]

@kenodegard @jaimergp How does this overlap with #5255?

[jaimergp]

Mostly compatible. We need to agree on a base exception for all conda-build exceptions, or just subclass CondaError for each one. I chose the former, but Ken's does:

class CondaBuildUserError(CondaError):
  ...

vs my idea:

class CondaBuildError(CondaError):
  ...

class CondaBuildUserError(CondaBuildError):
  ...

I don't mind either, but we need to agree on one.