Make mapper aliases configurable

[ml-evs]

This PR removes the default StructureMapper aliases and moves them to the default config.ini. They were previously quite annoying as you had to use these pseudo-MP field names if you didn't want to patch the our library yourself (i.e. if you were both creating and consuming your database using the optimade models).

• Added <endpoint>.aliases sections to config file, with blank defaults, similar to provider fields.
• ResourceMapper now pulls aliases from three places: the defined ALIASES class data, any config section config.aliases[ENDPOINT] and the config provider fields.

We should probably write some docs on how to use the aliasing features.

[codecov]

Codecov Report

Merging #175 into master will increase coverage by 0.07%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #175      +/-   ##
==========================================
+ Coverage   86.24%   86.31%   +0.07%     
==========================================
  Files          40       40              
  Lines        1868     1878      +10     
==========================================
+ Hits         1611     1621      +10     
  Misses        257      257

Flag	Coverage Δ
#unittests	86.31% <100%> (+0.07%)	⬆️

Impacted Files	Coverage Δ
optimade/server/mappers/entries.py	97.77% <ø> (ø)	⬆️
optimade/server/mappers/structures.py	100% <ø> (ø)	⬆️
optimade/server/config.py	94.87% <100%> (+0.53%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ee15c4a...d1f0ab7. Read the comment docs.

[CasperWA]

I must admit, I thought the point was that one implemented their own StructureMapper class and passing it to where it may be needed - but maybe this is not what you had in mind?

Note, I am not against this at all, I am only confused as to what the desired design goals are at the moment of this package/repository. What its prioritized purpose is (e.g., first and foremost a source for the models and filter grammar, then to be used to implement an index meta-database, then for a full implementation, etc.)

[ml-evs]

I must admit, I thought the point was that one implemented their own StructureMapper class and passing it to where it may be needed - but maybe this is not what you had in mind?

Absolutely, but the point should still be to make everything as reusable as possible. I know it's trivial to implement a structure mapper without aliases, but it's even more trivial to, er, not have to in the default case.

Note, I am not against this at all, I am only confused as to what the desired design goals are at the moment of this package/repository. What its prioritized purpose is (e.g., first and foremost a source for the models and filter grammar, then to be used to implement an index meta-database, then for a full implementation, etc.)

I agree with this ranking of the goals but I don't see this minor goal impeding on the rest. I would argue the aliases here are a special case where your fields perfectly align with the OPTiMaDe fields, asdie from their field names. I think a much more likely use case would be someone spinning up a new database for sharing results using the OPTiMaDe models from the get-go.

[CasperWA]

I must admit, I thought the point was that one implemented their own StructureMapper class and passing it to where it may be needed - but maybe this is not what you had in mind?

Absolutely, but the point should still be to make everything as reusable as possible. I know it's trivial to implement a structure mapper without aliases, but it's even more trivial to, er, not have to in the default case.

For sure. And agreed.

Note, I am not against this at all, I am only confused as to what the desired design goals are at the moment of this package/repository. What its prioritized purpose is (e.g., first and foremost a source for the models and filter grammar, then to be used to implement an index meta-database, then for a full implementation, etc.)

I agree with this ranking of the goals but I don't see this minor goal impeding on the rest. I would argue the aliases here are a special case where your fields perfectly align with the OPTiMaDe fields, asdie from their field names. I think a much more likely use case would be someone spinning up a new database for sharing results using the OPTiMaDe models from the get-go.

Perhaps. And I definitely don't see it impeding either.
In the end I was maybe just starting to re-raise the question of this repository's purpose. But will start an issue on this instead.

[CasperWA]

Looks good.
I've suggested some minor code optimizations in config.py.

[CasperWA]

LGTM, thanks @ml-evs