Fix data_returned and data_available

[CasperWA]

See the OPTiMaDe spec issue here.

data_returned is defined as the total number of data that can be returned using the passed parameters.
data_available is defined as the total number of data available of a certain type at any time.

data_available is saved "lazily", i.e., when the first request has been made, and then it is stored as a property for the specific collection instance.

Tests have been slightly updated to account for the fix.
Perhaps the expected data_returned value should be hard-coded?

[codecov]

Codecov Report

Merging #93 into master will increase coverage by <.01%.
The diff coverage is 81.48%.

@@            Coverage Diff             @@
##           master      #93      +/-   ##
==========================================
+ Coverage   85.06%   85.06%   +<.01%     
==========================================
  Files          38       38              
  Lines        2209     2210       +1     
==========================================
+ Hits         1879     1880       +1     
  Misses        330      330

Impacted Files	Coverage Δ
optimade/server/utils.py	64.28% <100%> (-0.43%)	⬇️
optimade/server/tests/test_server.py	88.7% <79.48%> (+0.09%)	⬆️
optimade/server/entry_collections.py	83.73% <84.61%> (ø)	⬆️

---

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 3d3f906...4ad7e88. Read the comment docs.

[ml-evs]

Thanks for clearing this up @CasperWA, I guess we all read the spec the same way.

I'm happy to approve at this stage, but have a minor comment. In the Mongo case, collection.count() will already use a cached value if no insertions/deletions have occurred, but obviously our value will become "out of date" if any have occurred. I guess this is just one of those implementation dependent things again, but calling count() explicitly every time makes sense to me as the number will always be correct if the number of documents has changed, and it shouldn't be much slower than the python cached version when it hasn't changed.

[CasperWA]

I'm happy to approve at this stage, but have a minor comment. In the Mongo case, collection.count() will already use a cached value if no insertions/deletions have occurred, but obviously our value will become "out of date" if any have occurred. I guess this is just one of those implementation dependent things again, but calling count() explicitly every time makes sense to me as the number will always be correct if the number of documents has changed, and it shouldn't be much slower than the python cached version when it hasn't changed.

Ah, didn't know this. And maybe it is just easier to actually use the implemented methods. I will remove the local "cache".