refactor: Get rid of `boost/algorithm/string.hpp` #24787

This PR replaces the boost/algorithm/string.hpp header with more granular ones which are already used in the codebase.

Such granulation, for example, guarantees that the boost/algorithm/string/trim.hpp header is not included indirectly, which in turn allows to remove boost::algorithm::trim* calls from the test/lint/lint-locale-dependence.sh linter.

Probably better to review #22953 instead of massaging these headers further?

Probably better to review #22953 instead of massaging these headers further?

Actually, it was one I started from. But, unfortunately, #22953 keeps test/lint/lint-includes.sh unpruned.

But, unfortunately, #22953 keeps test/lint/lint-includes.sh unpruned.

I don't think that matters. I'm saying there's not much advantage in having this PR turn (for example):

// src/wallet/rpc/backup.cpp
#include <boost/algorithm/string.hpp>

into

// src/wallet/rpc/backup.cpp
#include <boost/algorithm/string/classification.hpp>
#include <boost/algorithm/string/split.hpp>

just for the sake of pruning lint-includes.sh, if #22953 will just remove

// src/wallet/rpc/backup.cpp
#include <boost/algorithm/string.hpp>

entirely.

utACK. This PR makes sense to me. I understand the requests to replace boost string altogether with custom code, and I'd like that to happen at some point. But this is a seemingly trivial merge, if it builds, it's good, and it removes some boost includes. Seems like a win to me.

<!--e57a25ab6845829454e8d69fc972939a-->

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

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #24742 ([POC] build: prune Boost headers in depends by fanquake)
• #22953 (refactor: introduce single-separator split helper (boost::split replacement) by theStack)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

I'm going to close this in favour of #22953 and/or #24831.