Allow some condarc values in conda-forge.yml

[jakirkham]

Based on the values permitted in condarc, this takes a subset that looks safe for users to configure (and are not already provided some other way) and lets users add them to conda-forge.yml under the conda key. This can be useful when workaround a Conda idiosyncrasy in a particular feedstock build, for adjusting debug information, configuring threads for some operations, or enabling additional safety or error checks.

---

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[jaimergp]

Do we want these to affect the initial conda installation with Miniforge (when conda_install_tool = conda)? Because in that case, ci-setup is a bit too late for that and we'd need it in conda-smithy + rerender.

If not, the only comment I have is that this should also be added to the conda-forge.yml schema in conda-smithy.

[jakirkham]

I didn't think so. Figured the purpose of this would be to affect things related to the build that are simply outside the conda_build key

Certainly it would be possible to expand the affected parts of the build later

Yep that makes sense. Wanted to wait and see if there were thoughts on this change before writing more pieces

[beckermr]

LGTM and thank you!

[beckermr]

Thought for a future PR. Do we want to support a single condarc key instead of the two conda-build and conda keys?

[isuruf]

We should keep this allowlist in conda-smithy, so that we can lint.