index: Delete legacy coinstats index folder #35534

Description

This resolves the TODO to delete the legacy coinstats index folder located at indexes/coinstats if it exists.

To ensure safety and prevent node startup crashes (e.g., due to permission locks or locked directories), i have used fs::remove_all with std::error_code to intercept errors and log warning instead.

Testing/Verification

• Verified compilation of coinstatsindex.cpp under AppleClang 17.0.0.
• This is how i tested it:
  1. Create a dummy indexes/coinstats directory inside your Bitcoin data directory.
  2. Start bitcoind with -coinstatsindex.
  3. Verify that the indexes/coinstats directory is successfully removed and the debug log prints: Deleted old coinstatsindex directory at ...

<!-- *** Please remove the following help text before submitting: *** Pull requests without a rationale and clear improvement may be closed immediately. GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->

<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. -->

<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. -->

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35534.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

To ensure safety and prevent node startup crashes (e.g., due to permission locks or locked directories)

Can you give instructions on how to reproduce this?

We should keep it around at least until v29 is not supported anymore, which it still is, unless there is a real issue with this.

We should keep it around at least until v29 is not supported anymore, which it still is, unless there is a real issue with this.

Indeed, closing.

To ensure safety and prevent node startup crashes (e.g., due to permission locks or locked directories)

Can you give instructions on how to reproduce this?

Hello sir,

If the directory is locked for any reason (e.g., antivirus software or another script that locks it due to a process), an error will be thrown, which is never caught, and the program could crash.

There may be a gap in my understanding of the code; apologies for any inconvenience.

Thank you for your time! Jay

We should keep it around at least until v29 is not supported anymore, which it still is, unless there is a real issue with this.

Indeed, closing.

Okay!!