Pip for ci (PR 605) follow-on work

[Charles Stern]

A few future directions for follow-on work to complement #605:

• Restore GRIB testing with a separate requires-conda test setup somewhere
• Catching issues like #603 is nice, so we should generally try to test against conda environments somewhere, but maybe on conda-forge/pangeo-forge-recipes-feedstock?
• It's good to have the upstream-dev testing (and we should probably include Zarr-python there) but it's a big heavy to run on every commit. Maybe we can move that to nightly runs on a chron schedule?
  • Edit: Completed in #607

Originally posted by @cisaacstern in #605 (comment)

[Justus Magin]

A few hints here:

• for conda in CI mamba-org/setup-micromamba is a good option as it is generally much faster than setup-miniconda and it has built-in environment caching, which on cache hit means that the environment can be set up in <10s (but this appears to heavily depend on the CI worker spec, since windows and macos CI often take longer than that).
• for scheduled upstream-dev I like using xarray-contrib/issue-from-pytest-log (though I'm the main author of that, so 🤷) to open an issue as soon as the upstream-dev CI fails, which makes failures a bit more visible