BugFix: Close all FDBFileHandle on TocStore destruction

[tbkr]

Description

FDBFileHandles weren't closed and leaked across several executions of tests with a shared, long-living FDB object.
See ECKIT-670.

Contributor Declaration

By opening this pull request, I affirm the following:

• All authors agree to the Contributor License Agreement.
• The code follows the project's coding standards.
• I have performed self-review and added comments where needed.
• I have added or updated tests to verify that my changes are effective and functional.
• I have run all existing tests and confirmed they pass.

🌈🌦️📖🚧 Documentation Z3FDB 🚧📖🌦️🌈
https://sites.ecmwf.int/docs/dev-section/z3fdb/pull-requests/PR-228

🌈🌦️📖🚧 Documentation FDB 🚧📖🌦️🌈
https://sites.ecmwf.int/docs/dev-section/fdb/pull-requests/PR-228

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.38%. Comparing base (8f06994) to head (99894e7).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #228      +/-   ##
===========================================
+ Coverage    73.32%   73.38%   +0.06%     
===========================================
  Files          363      363              
  Lines        21976    21976              
  Branches      2259     2259              
===========================================
+ Hits         16113    16128      +15     
+ Misses        5863     5848      -15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[simondsmart]

I'm not sure I like this fix.

The close() function exists, because we moved close-related functionality out of the constructor. This is because any exceptions thrown in a destructor will cause std::terminate if we happen to hit he destructor due to stack unwinding from another exception being thrown.

This is particularly important not in the TocStore, but in the Remote Store funtionality where close() is a non-trivial operation.

In all contexts, a Store should be being owned by something. This strongly suggests that our ownership semantics are wrong. Can we check the locations where stores are being owned, and make sure that the plumbing is called correctly.

I would feel much more comfortable with as ASSERT, or at the very least Log::warn() output being written, if the destructor is hit before close() is called.