Refactor catalog utils (again)

[aulemahal]

Pull Request Checklist:

• [x] This PR addresses an already opened issue (for bug fixes / features)
  • This PR fixes #152.
• [x] (If applicable) Documentation has been added / updated (for bug fixes / features)
• [x] This PR does not seem to break the templates.
• [x] HISTORY.rst has been updated (with summary of main changes)
  • [ ] Link to issue (:issue:number) and pull request (:pull:number) has been added

What kind of change does this PR introduce?

• Move catalog creation (parse_directory) to a new catutils.py module
• Rewrite file parsing functions:
  • Use os.walk instead of subprocess calling find. The function should now be platform independent and not linux-specific.
  • Use parse instead of intake.source.utils.reverse_format. It allows some interesting features, like format specifiers.
  • Rethink parallelism.
  • More flexibility to cvs
• Copy and adapt path building stuff from miranda. See build_path. Schema is data/file_schema.yml.
• date_parser has moved to utils.py.

Does this PR introduce a breaking change?

Yes.

• Functions have moved.
• Patterns feeded to parse_directory are now specified differently. See doc and example below.
• No more globpattern. The extension is parsed from the patterns. Calls can now mix different extensions. A new dirglob arg takes care of the "folder filtering" feature.
• parse_directory does not use dask anymore. I believe the code is now easier to understand and speed is not affected too much. Parsing a local filesystem is not supposed to be faster in parallel, but we are often using nfs-mounted disk where this is less true. Testing on doris, parsing the full /datasets/simulation/raw folder takes the same time between the new and the old versions. See note below on "code complexity".

Other information:

Example for the new patterns:

OLD: {processing_level}/{mip_era}/{activity}/{domain}/{institution}/{source}/{experiment}/{member}/{frequency}/{_variable}/{?var}_{?freq}_{?src}_{?exp}_{?memb}_{*}_{date_start}-{date_end}.nc"

NEW : "{processing_level}/{mip_era}/{activity}/{domain}/{institution}/{source}/{experiment}/{member}/{frequency}/{variable:_}/{*}_{DATES}.nc"

The "variable" field accepts underscores, so it uses the "_" format specifier. No more need to specify each part of the filename if only the last one is needed. Here the "DATES" special field can catch single dates or bounds.

TODO:

• ~Update the notebooks~

Code complexity

Lol. I thought this PR would simplify the parse_directory system.

The problem is the MRCC5. Or at least, it is the enormous size of this database and its scattering on slow-to-read disks. It is the only reason for all these complexities:

• Queues to multithread the file parsing
• Access checks because there are non-readable files in the database.
• Multiprocessing pool for parallelize the disks parsing
• "read_file" by groups to minimize the number of file reads.
• Parsing from file with fast-paths for netCDF and Zarr (instead of xarray).
• Nested CVS (although this new feature could be useful in other databases)

I wanted to make clear that the complexity of this code is NOT only because I like to optimize things. Last time I ran the MRCC5 catalog creation (with this code), it took 7 hours. Just imagine without the optimizations. (And this while missing a full disk).

[RondeauG]

If you could use this PR to also address #152, that would be great! I wrote the issue, but it originally came from @mccrayc, so you can check with him for the details.

[mccrayc]

Looks good to me! The new patterns seem much more intuitive and clean.

[aulemahal]

Last commit made a few changes. I tested the new code with ouranos_data_catalogs and it made a few bugs appear:

• _parse_from_zarr can now read the time coordinate. Before, xarray was needed, which was slowing down the process a lot.
• Removed split_dataset, this is to be implemented in another PR.
• Relaxed the "dates" regex to dates of any length.
• Added a test in parse_directory to remove entries where date_start is a date, but frequency is "fx".

And I guess I now need to add tests!

[aulemahal]

+12% coverage :muscle: