Significantly enhance the safety of metadata manipulation

[benoit74]

Fix #205

Changes

• make config_metadata much stricter around standard metadata
  • add new StandardMetadata class for standard metadata
  • add way more typing around metadata manipulation with RawMetadataValue, CleanMetadataValue and Metadata
• add config_any_metadata for those who need to add custom ones
• systematically cleanup / convert / check all metadata values for our constraints and conventions
• ensure that add_metadata does same cleanup / checks as config_metadata and config_any_metadata
• move constants and validation logic for metadata to zim/metadata.py
  • from creator.py: MANDATORY_ZIM_METADATA_KEYS, DEFAULT_DEV_ZIM_METADATA, RECOMMENDED_MAX_TITLE_LENGTH, MAXIMUM_DESCRIPTION_METADATA_LENGTH, MAXIMUM_LONG_DESCRIPTION_METADATA_LENGTH, ILLUSTRATIONS_METADATA_RE
  • from creator.py: convert_and_check_metadata

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (7d1b958) to head (0e764ed).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## data_src #217 +/- ## ========================================== Coverage 100.00% 100.00% ========================================== Files 38 38 Lines 2224 2278 +54 Branches 426 435 +9 ========================================== + Hits 2224 2278 +54 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[benoit74]

I like the approach but I'm not a fan of extending the API with config_any_metadata(). I dont have much argument beside it being another piece of API to maintain and the relative confusion it introduces: one has to dig into docstring to understand what to use.

Indeed, it is "a shame" to have two APIs where one with two arguments would suffice. I already simplified a lot compared to original code I wrote but I have to admit I could go even one step further.

I also wonder if we need all this flexibility: Metadata, list of metadata, dict of key/value pairs ?

I'm a bit uncertain on this. dict of key/value pairs is nice for its brevity ... but it's poorly typed, and the past has shown that typed objects might help. At the same time, here we really have no idea of what these metadata can be, so a dict is probably sufficient and the Metadata object does not bring much clarity.

[rgaudin]

I'm a bit uncertain on this. dict of key/value pairs is nice for its brevity ... but it's poorly typed, and the past has shown that typed objects might help. At the same time, here we really have no idea of what these metadata can be, so a dict is probably sufficient and the Metadata object does not bring much clarity.

Yes, I want to say it's easier to extend later when there's a need than to maintain potential use cases but it's really up to you. It's not not a big deal either way

[benoit74]

Superseeded by https://github.com/openzim/python-scraperlib/pull/221