Refactor and simplify testing data fetching

[Zeitsperre]

Changes

• Added h5netcdf as a core dependency, acting as a backup engine for reading netcdf files.
• Made use of model_copy(deep=True) when dealing with Raven configs in the testing suite.
• Updated autodoc-pydantic for compatibility with pydantic v2.0+
• Modified some session-scoped pytest fixtures that were causing problems in other tests.
• Removed the redundant emulators-based pytest fixtures; These are now loaded from emulators.py in the tests folder.

[coveralls]

coverage: 81.5%. first build
when pulling 346cf8f on set_netcdf4
into 021ef31 on master.

[Zeitsperre]

@huard

I've been really digging into this to see what's going on, and I can confidently say the following:

• There are a few pytest fixtures that are session-scoped (i.e. They are created once when first called and persist between tests). When functions modify the internals of the objects and are then passed to other tests, things get weird. This was causing several problems with threads: likely from reading data from objects that are being written in the course of running other tests. I've fixed this by copying data objects (using model_copy(deep=True) or by copying the file itself to a tmp_dir)
• There are a few methods in the code for emulators that will modify any NetCDF objects/files passed to them (like from_nc). This is kind of unsafe. Is there a reason for this (are there features necessary on mutating the original NetCDF files passed to them)? If not, dealing with this (via model_copy(deep=True)?) should be the next step.
• For the session-scoped pytest emulator fixtures, would it be safe to make them test-scoped instead?
• I've added h5netcdf as a backend for reading datasets in ravenpy.config.commands. I've found it to be much more stable than python-netcdf4. This could probably be set up in other functions that read NetCDF files as well. (Ideally, we shouldn't have too many functions doing IO for NetCDF files; Is there a way to combine these file-loaders into a single utility?)

Let me know what you think about this so far. I see this PR as a bandage for the testing issues (much more stable) but once I can find the time to replace everything with pooch I can rewrite much more of the testing suite.

[huard]

Everything looks good, thanks for looking into this. There is no reason for from_nc to modify the dataset. Where do you see this happening ?

[Zeitsperre]

There is no reason for from_nc to modify the dataset. Where do you see this happening ?

My bad, I was thinking of the *climatology_esp functions. It clearly states that the config objects are modified when passed to them. I take that approach in a few functions used in Miranda (modifying classes via functions, not methods) as well.

I'll update the change log here, and hopefully we should have a (relatively) more stable testing experience going forwards.