Retrieve all conda-store environments

[soapy1]

Reference Issues or PRs

Fixes #2599

What does this implement/fix?

Put a x in the boxes that apply

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds a feature)
• Breaking change (fix or feature that would cause existing features not to work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build related changes
• Other (please describe):

Testing

• Did you test the pull request locally?
• Did you add new tests?

How to test this PR?

0. To test this PR you must have
   a. an installation of Nebari with jhub apps enabled
   b. at least 100 conda-store environments (or decrease the size_limit var in the PR to a sufficiently small number, like 2)
1. Navigate to the nebari home screen
2. Click on the deploy app button
3. Click on the drop down to select the conda store environment for the app
4. Notice that all the environments are available

Any other comments?

Note, that this API endpoint has the following known bug conda-incubator/conda-store#859.

Users may be able to get around this issue by refreshing the page to get the updated set of environments.

[soapy1]

I took a look around the code base to find where unit tests for this should go, but I could not find anything obvious. Would love some advice on where a good spot for a test would be. Thanks 🐎

[viniciusdc]

I was following up on the discussion and had a meeting with Chuck as well; right now, nebari does not have a good architecture to test internal /stages Python code fully; it's basically in another realm than the Nebari package itself. Unless we did something in the direction of explicitly initializing each nested folder as a Python submodule, we can't easily import such methods.

I do like the overall idea and the sound of that, though this might be something to another PR, my suggestion would be to implement the pure method @dcmcand commented above for the URL string list generation and leave there for another PR where we make it possible to be unit-tested.

Regarding the discussion for the default value of PAGE_SIZE_LIMIT, I also agree that this should be overridable somehow; I would prefer this to be configurable somewhere, maybe via trait lets in the future, but right now, just allowing it to be changed by an environment variable might be enough.