Improve test diagnostics and fix deprecated Elasticsearch calls

[ml-evs]

This PR does the following:

• treat deprecation warnings as errors unless they are explicitly ignored
• enables coloured outputs in CI with pytest
• moves pytest config to setup.cfg instead of pytest.ini
• attempts to filter more warnings out of pytest output (this is still not working quite as I'd hoped)
• Fixes some deprecated Elasticsearch calls, and pins the version of the underlying elasticsearch dependency (not elasticsearch_dsl)
• Pins FastAPI to 0.86 in setup.py due to issues with 0.87

Hopefully now we will get proper test errors for important warnings from e.g. dependencies.

Closes #1377 (I think) and #1388

[codecov]

Codecov Report

Merging #1373 (41eed44) into master (2394476) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #1373   +/-   ##
=======================================
  Coverage   91.46%   91.46%           
=======================================
  Files          72       72           
  Lines        4369     4369           
=======================================
  Hits         3996     3996           
  Misses        373      373           

Flag	Coverage Δ
project	91.46% <100.00%> (ø)
validator	91.52% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
optimade/server/config.py	93.54% <100.00%> (ø)
optimade/server/entry_collections/elasticsearch.py	97.53% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[JPBergsma]

Is it necessary to explicitly define the elastic search version?
elasticsearch-dsl depends on elasticsearch, so it should be installed without specifying it directly.

[ml-evs]

I think so, yes. Different versions of elasticsearch are introducing different functionality that elasticsearch-dsl is making use of in different ways. Currently DLS is making deprecated calls to the underlying package without pinning the version, so if we want to avoid deprecation warnings ourselves then I think this is the only choice.

[JPBergsma]

Do you mean that we get deprecation warnings because the elasticsearch version is too old ?
And that elasticsearch it is not automatically updated when we update elasticsearch-dsl ?

[ml-evs]

We get them because elasticsearch_dsl is using the Python API defined in elasticsearch (the Python package) but is not completely up to date itself (and does not pin a specific version as it is a library).

[JPBergsma]

So does Elasticsearch-dsl give you a deprecation warning when you use an older version(e.g. 7.1) of Elasticsearch ?
Anyway, I do not think this is a big enough issue to hold back this PR, so I have approved it.

[ml-evs]

The Python client elasticsearch (not the database) follows the same version convention as the database, but elasticsearch_dsl (the higher-level interface) just uses the major version to say they support v7 of the database. We were directly making calls to the low-level elasticsearch Python API (without adding it as an explicit dependency, until this PR) that have been deprecated (fixed in this PR), but the DSL is still making similar deprecated calls that we cannot fix at our end - I have added these to the pytest ignore list. As elasticsearch-dsl does not tightly pin the version of elasticsearch Python API, there is a chance that those calls get removed in a later version, which would also break our package unless we pin it.