Replace Boost with std library.

[nathanielcwm]

Builds on #1378. List of possible changes can be found on the old issue.

AFAIK the refactor #2113 did not address the issue of Boost libraries still being used when the functionality is now available in the std library.

[nathanielcwm]

Looks like Parallel Algorithms is now supported but only in GCC 9 (requires Ubuntu 20.04) & not Clang.

Also requires a linker flag of -ltbb

[jamescowens]

We are not going to rewrite code for C++17 just for the sake of implementing new standards unless there is a CLEAR cost-benefit to doing so. We also have to be careful about adjusting the style in Bitcoin Core code, especially code that has already been ported from Bitcoin Core relatively recently, to ensure we do not create future merging/port problems.

I do agree that we should work on replacing other boost functionality with the std counterparts AS LONG AS the std equivalents implement the same or better functionality and do not cause regression issues. Unlike Bitcoin Core, there are parts of our code that make significant use of boost functions that are not likely to be in the std library for quite some time, and are not in the C++17 std, so we will not be able to eliminate boost anytime soon.

As a matter of note, much of the new standard library additions have come straight from boost, with a few tweaks. So I am not sure what people have against it....

[nathanielcwm]

Looks like Core is actually making an effort towards moving away from Boost after their move to C++ 17.

This was a large part of the old C++17 issue so I feel like keeping this open, possibly to track Bitcoin changes too, is warranted.

[jamescowens]

We will move away from boost too where equivalent functionality has been implemented in std.

[denravonska]

C++ functionality tend to be developed in Boost, refined and then implemented in the standard with no or minor modifications. In many cases it should be safe to migrate just by replacing the namespace, while in others it'll need some love to adapt to a modified API.

@jamescowens is right though, it might be better to pull the boost removal from upstream if the changes are expected to arrive in a reasonable timeframe. If Core is moving far too slow it could be beneficial to just do the changes locally and pay the merge cost later.