ODC environment configuration

[SpacemanPaul]

Better ODC/OWS configuration integration.

• Completely retire old connection pool API and have config layer manage access to datacube index objects.
• Allow user to specify ODC environment in OWS config (rather than always using the default) (and document)

The are hooks for overriding the ODC environment per layer - so multi-database support. But more work needs to be done cleaning up the range table schema and code before that can be turned on.

Also refactored some variable names to reduce confusions with ODC products and OWS layers.

Oh and I turned off isort in pre-commit because I've never liked the way it formats multi-line imports and the order of imports isn't that important to begin with, imo.

[SpacemanPaul]

Ugh. Now the unit testing framework for testing without a database is broken (works fine at home where it can just connect to a database). I'm going to have to monkeypatch.

[codecov]

Codecov Report

Attention: Patch coverage is 91.70507% with 36 lines in your changes missing coverage. Please review.

Project coverage is 93.77%. Comparing base (155ad3e) to head (722bc6e).
Report is 47 commits behind head on develop-1.9.

Files with missing lines	Patch %	Lines
datacube_ows/feature_info.py	82.27%	14 Missing ⚠️
datacube_ows/data.py	89.88%	9 Missing ⚠️
datacube_ows/wcs2_utils.py	93.57%	7 Missing ⚠️
datacube_ows/wcs1_utils.py	91.22%	5 Missing ⚠️
datacube_ows/config_utils.py	93.33%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           develop-1.9    #1015   +/-   ##
============================================
  Coverage        93.77%   93.77%           
============================================
  Files               47       46    -1     
  Lines             6631     6573   -58     
============================================
- Hits              6218     6164   -54     
+ Misses             413      409    -4     

Files with missing lines	Coverage Δ
datacube_ows/ogc.py	84.96% <100.00%> (-0.23%)	⬇️
datacube_ows/ows_configuration.py	95.69% <100.00%> (+0.02%)	⬆️
datacube_ows/product_ranges.py	84.91% <100.00%> (-0.09%)	⬇️
datacube_ows/styles/base.py	95.91% <100.00%> (ø)
datacube_ows/styles/component.py	93.61% <100.00%> (ø)
datacube_ows/wcs1.py	100.00% <100.00%> (ø)
datacube_ows/wms_utils.py	92.08% <100.00%> (ø)
datacube_ows/config_utils.py	94.58% <93.33%> (ø)
datacube_ows/wcs1_utils.py	95.25% <91.22%> (+0.34%)	⬆️
datacube_ows/wcs2_utils.py	91.95% <93.57%> (+0.29%)	⬆️
... and 2 more

[pjonsson]

I think the main point(s) of having an isort-like tool is that you never get duplicate imports when merging/cherry-picking/etc, and you avoid spurious merge conflicts because one commit does from A import B, C and the other commit does from A import C, B.

My experience with black+isort/clang-format is that they are massive productivity boosters because the bikeshedding about formatting is eliminated, there's a program that mechanically decides if things are well-formatted or not and all you have to do to comply is run that program.

[omad]

Looks massive, but, sure... I guess. And Thank you.