doc: add C++17 release note for 0.21.0

[fanquake]

TLDR: Mention that the codebase is now compatible with C++17, and that the
intention is to require C++17 starting with 0.22.0.

Following some discussion with Cory/Carl, and in #16684, I think this is the next step in the C++17 migration.

While #16684 mentions a gitian/Guix release with C++17, it's not yet clear how that would be done. Are we just going to pass --enable-c++17 in gitian/Guix?. Are we changing our default in configure.ac?

According to the last comment in #16684, we wouldn't be changing anything in depends:

No, everything (including depends) will stay at C++11.

However I don't think we want to be mixing C++11 built dependencies, with a C++17 built bitcoind, if there is any potential for compatibility issues.

Instead, I'd suggest we build the 0.21.0 release as C++11, and do a complete switch to C++17 for 0.22.0. Also, if we actually wanted to use C++17 in depends for 0.21.0, we couldn't without breaking C++11 compat (Qt). See below.

Here is a potential timeline/TODOs for the migration:

Potential Timeline

• 17 / 6 / 2020 - Today
• Some time prior to split-off:
  • Confirm that compiling with C++17 works.
  • Confirm that C++11 compatibility has not been broken.
• 1 / 11 / 2020
  • 0.21.0 split off happens.
• 2 / 11 / 2020
  • Merge an "incompatible with C++11" change into master.
  • Switch configure to use C++17 mode by default.
  • Update minimum compiler requirements. At least:
    • Clang 5: https://clang.llvm.org/cxx_status.html#cxx17
    • GCC 7: https://gcc.gnu.org/projects/cxx-status.html#cxx17
      • While GCC has some support from 5, it seems a more complete support landed in GCC 7.
      • https://gcc.gnu.org/gcc-7/changes.html#cxx
  • Switch depends packages to use C++17 where applicable.
  • Bump Qt from 5.9.x (no c++17 mode) to, likely, 5.15.x (LTS).
  • Drop support for macOS < 10.14.x
    • The c++ dylib shipped with macOS doesn't support c++17, prior to macOS 10.14.
    • Building Qt 5.12 or 5.15 in C++17 mode will also require a minimum macOS deployment target of 10.14. https://codereview.qt-project.org/c/qt/qtbase/+/283832.
  • Begin merging PRs like [WIP DONOTMERGE] Replace boost with C++17 (std::shared_mutex) #19183 and Replace boost::filesystem with std::filesystem #19245.
    • I've left some comments in [WIP DONOTMERGE] Replace boost with C++17 (std::shared_mutex) #19183 if the macOS runtime issue interests anyone.
• 3 / 12 / 2020
  • 0.21.0 released.
  • Built as C++11.
  • Contains warning in release notes that compiling 0.22.0 will require C++17.
• 3 / 6 / 2021
  • 0.22.0 released.
  • Full of C++17 code.

One thing worth noting, is that we cannot bump our Qt to a newer LTS for 0.21.0, without breaking C++11 compatibility. Qt 5.12 is not compilable in C++11 mode, as the project has started using C++14 features throughout at least the macOS portions of it's codebase, and seemingly "forgotten" that the release is meant to be C++11 compatible.
Upstream bug here: https://bugreports.qt.io/browse/QTBUG-77310.

Building Qt requires C+11, at a minimum, but in practice we use later features, usually under a feature define, or with a fallback of some kind. On platforms that support > C11, we've (apparently) not considered the fallback necessary, under the assumption C+14 is always available.

[maflcko]

ACK f1d21ef can't hurt to give an advance warning

[maflcko]

Some time prior to split-off:

Confirm that compiling with C++17 works.
Confirm that C++11 compatibility has not been broken.

our current ci configs should take care of this already

[theStack]

ACK f1d21ef

[Sjors]

ACK f1d21ef

One thing worth noting, is that we cannot bump our Qt to a newer LTS for 0.21.0, without breaking C++11 compatibility.

Perusing all open GUI issues old repo / new repo I don't see any burning issues that need a version bump. In other words, happy to wait for 0.22. Regardless, I look forward to the 0.21.0 branch-off.

Bump Qt from 5.9.x (no c++17 mode) to, likely, 5.15.x (LTS)

Unfortunately QT retroactively dropped LTS for 5.15 (see #18580), i.e. it's commercial support only. But as @MarcoFalke pointed out:

I don't think we have a choice. Now that they dropped LTS, all we can do is follow their latest open source release

It's certainly doesn't seem like a reason to stick to a c++11 version of QT, since those aren't maintained at all, making it mostly an orthogonal concern.

[JeremyRubin]

This seems consistent with #16684 (comment)

I would add a note that 0.21 backports and minor versions may begin requiring C++17 as well, depending on what they are (e.g., if consensus code gets added using a C++17 feature, the soft fork rules would require C++17). As such, it's reasonable to say that 0.21.0 is the last version a user should expect to be compatible with C++11.

[laanwj]

ACK f1d21ef