Sort envs returned by REST API by current build's scheduled_on time

[peytondmurray]

Fixes #859.

Description

This PR sorts environments returned when a GET is sent to /environment/ by the time the environments' current builds were submitted. In systems where users are creating environments while environments are being queried, this ensures that all results are returned; other sorting methods (e.g. by name) can yield incomplete results.

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)?

[netlify]

✅ Deploy Preview for conda-store canceled.

Name	Link
🔨 Latest commit	129793d
🔍 Latest deploy log	https://app.netlify.com/sites/conda-store/deploys/679178c25c5b51000860ef46

[peytondmurray]

After a discussion, it seems like no matter how we solve this there's going to be a breaking change to the API. Cursor-based pagination will allow for any sorting order, so I'll look into implementing that, probably through fastapi-pagination.

[peytondmurray]

Adding pagination via fastapi-pagination seems simple on the surface, but they don't publish an API reference in the docs, so without reading the source for the project I'm not sure how it affects what query parameters are accepted by our API. So in the process of trying to implement this, I started working on adding hot reloading, but due to the fact that we're using traitlets to load server configuration (and instantiate the FastAPI app) and that uvicorn has specific requirements about how the FastAPI app is instantiated when hot reloading, it's trickier to get this working than I thought. See #901 for details.

[peytondmurray]

Hot reloading's done, but the fastapi_pagination docs aren't enough to get this working easily, and in the time it would take to actually read through the source for the project I think we can just implement a simple cursor-based paginator instead :/

[peytondmurray]

Not sure if this is actually ready to be merged, as it is not currently compatible with the frontend, and a discussion about REST API versioning needs to be had before this approach can be merged. But otherwise, tests are passing and the implementation is I think mostly complete :) @soapy1

[soapy1]

Looking good! Thank you for adding such beautiful formatted and thorough docs to a lot of these functions 🤩

Just a few things to sort out.

I took notes on what I tested manually in this gist https://gist.github.com/soapy1/beae935f78725cfd1dd0897c1ce016d4

[soapy1]

One more question (related to how we want to approach versioning for this change): how do we want to approach pagination for the rest of the api? Do we want all the other endpoints to also adopt this type of pagination?

[peytondmurray]

I vote yes - as far as I can tell the advantages of limit/offset are that it's easy to implement, but the cost of it is exactly what is described in #859. Cursor based pagination addresses that.

[peytondmurray]

The cursor-based pagination is now on /api/v2/environment/, and /api/v1/environment/ has been restored as well. Ready for a second look!

[soapy1]

Looks great! Just 2 small changes suggested

[soapy1]

Looks great 📃