Privatize internal conda-store API

[peytondmurray]

Closes #723.

Description

This PR privatizes most of conda-store and conda-store-server in preparation for implementing an upcoming backwards compatibility policy.

This pull request:

• Moves everything into _internal subpackages, except for a select few outward-facing APIs.

Pull request checklist

• Did you test this change locally?
• Did you update the documentation (if required)?
• Did you add/update relevant tests for this change (if required)?

Additional information

How to test

No special testing requirements because new behavior has not been introduced; standard CI tests are sufficient.

[netlify]

✅ Deploy Preview for conda-store canceled.

Name	Link
🔨 Latest commit	561881e
🔍 Latest deploy log	https://app.netlify.com/sites/conda-store/deploys/6673289a6081190008a78f19

[dcmcand]

@peytondmurray, I am assuming that every function you left in the pubblic namespace either corresponds to a public rest api route or is used by the conda-store-ui, is that correct. I think this PR is great, I just want to double check that there aren't any little helper functions or anything that we could privatize. They wouldn't need to move to the _internal namespace imo, just have prepend them with a _. I am approving this based on the above assumption, but you might want to take another look through to see if any of the functions that are public could be privatized.

[pavithraes]

@peytondmurray Thanks for the PR.

Moves everything into _internal subpackages, except for a select few outward-facing APIs.

Verified this, and looks good to me. :)

From a design POV, would it make sense to actually move some configuration options (example configs, Nebari's conda-store config) out of _internal? If end-users need to set these config values to deploy conda-store, I'd expect these to be served by our compatibility policy.

[peytondmurray]

100%, you're right. I'll move anything that contains subclasses of LoggingConfigurable back out so that they're exposed to the user.