…n to 10

fa5423b refactor: Remove unused gcc-9 workaround in txrequest (MarcoFalke)
fa918d3 Always enable -Wsuggest-override (MarcoFalke)
faea58e Bump g++ minimum supported version to 10 (MarcoFalke)

Pull request description:

  All supported operating systems ship with g++ 10 (or later), so bumping the minimum should not cause any issues. The bump allows to drop some now-unused workarounds.

  For reference:
  * https://packages.debian.org/bullseye/g++ (`g++-10`)
  * https://packages.ubuntu.com/focal/g++-10
  * FreeBSD 12/13 ships with g++ 12
  * CentOS-like 9 ships with g++ 11
  * OpenSuse Tumbleweed ships with g++ 13 https://software.opensuse.org/package/gcc13-c++ (No idea about OpenSuse Leap)

  This is for Bitcoin Core 27.0 in 2024 (next year), not the soon upcoming 26.0 next month.

ACKs for top commit:
  fanquake:
    ACK fa5423b

Tree-SHA512: 6f0697ae4c0f578873591b7872bf158aba3af17f171c3556b593a70ec379bf94c7a9dd7697e8e79173edd4ac3c81a376e0cbbc0cfabde1a1cfe5f9b5eaea6831

fix: add update alternatives for arm gcc
fix: add update alternatives for arm g++

ff42d81 guix: use clang-toolchain-15 for macOS compilation (fanquake)
94955b4 depends: use LLVM/Clang 15.0.6 for macOS cross-compile (fanquake)

Pull request description:

  This will end up being a blocker for bitcoin#28210, and is already part of bitcoin#21778, even though an even newer LLVM/Clang combination is required (and still missing from upstream Guix). Seems straight-forward enough to just bump the macOS compiler to a more modern Clang.

ACKs for top commit:
  TheCharlatan:
    re-ACK ff42d81

Tree-SHA512: 8af4b54c3a56abb3825c6470444a28e14e9c69820c09ec4a33acebb8ae434df9ae18163c088a582130cc68755293a7e2bde5d065763919d94064ff9b3f83730f

fa7dada build: update ax_cxx_compile_stdcxx to serial 14 (MarcoFalke)

Pull request description:

  No strong reason for the bump, but this makes it easier to experiment with cpp20, see bitcoin#24169 (comment)

ACKs for top commit:
  Empact:
    Code Review ACK bitcoin@fa7dada
  fanquake:
    ACK fa7dada

Tree-SHA512: bd3e884bae5319d434520a2947608913c3884de89aa563aa46ef17ba4e5b41ba209bd4780c8eaf81648297b2dc9534803be88d1b214ad05a93ee5992bee887c0

fa6e50d fuzz: Use C++20 starts_with in rpc.cpp (MarcoFalke)
faa4838 Revert "tracepoints: Disables `-Wgnu-zero-variadic-macro-arguments` to compile without warnings" (MarcoFalke)
fae3b77 refactor: Drop unused _Pragma to ignore -Wgnu-zero-variadic-macro-arguments (MarcoFalke)
fa02fc0 refactor: modernize-use-default-member-init for bit-fields (C++20) (MarcoFalke)
fa67f09 build: Require C++20 compiler (MarcoFalke)

Pull request description:

  C++20 allows to write safer code, because it allows to enforce more stuff at compile time (`constinit`, `conteval`, `constexpr`, `std::span`, ...).

  Also, it allows to write less verbose and easier to understand code (C++ 20 Concepts).

  See bitcoin#23363 and https://en.cppreference.com/w/cpp/compiler_support#cpp20

  With g++-10 (bitcoin#28348) and clang-13 (bitcoin#28210), there is broad support for almost all features of C++20.

  It should be fine to require a C++20 compiler for Bitcoin Core 27.0 in 2024 (next year), not the soon upcoming 26.0 next month.

  This pull request includes three small cleanups to make use of C++20 features. If any issues are detected before or after merge, this should be easy to revert. If no issues arise, it should be fine to make use of more involved C++20 features later on.

ACKs for top commit:
  fanquake:
    ACK fa6e50d

Tree-SHA512: 244d79bfb0b750a4bdd713f40573b9ca33816fb84b6c84a58f027b9d7d4bb0cc4f18642959e4cf3d094808a69e5b8a327ca8521d7c0c08af27dacb5da3e78e71

… prepare for building with upstream LLVM

3df6070 contrib: remove macOS lazy_bind check (fanquake)
9bc357e build: explicitly opt-in to new fixup_chains functionality for darwin (Cory Fields)
fb61bc0 depends: Bump MacOS minimum runtime requirement to 11.0 (Cory Fields)
c2cd472 depends: bump darwin clang to 11.1 (Cory Fields)

Pull request description:

  This (I believe) resolves the last of the blockers for [switching us away from cctools and instead using out-of-the-box llvm and lld](bitcoin#21778) for building Darwin binaries.

  For now, we continue building with a pre-packaged llvm and cctools, but after this PR the clang+lld combo should just work for anyone trying it. Additionally after this PR, the new runtime `fixup_chains` behavior will be in-use, as ld64 uses it as well.

  The commits may seem unrelated, so in detail:

  lld (llvm's linker) has been a work-in-progress for Darwin for years. Recently though, it has gained nearly all of the features we require. The last missing feature from ld64, `-Wl,-bind_at_load`, is not implemented in lld; as far as I can tell [lazy loading has conceptually been replaced by fixup chains](https://www.emergetools.com/blog/posts/iOS15LaunchTime).

  So that means we don't need ld64's `bind_at_load` as long as lld can handle `-Wl,-fixup_chains` (which it can). I've added it to our configure as a linker option mostly so that we can see it in the logs; it's default-on as long as the minimum version is >11.0.

  About that: the runtime functionality required for `-Wl,-fixup_chains` [requires macOS >=11.0](https://github.com/llvm/llvm-project/blob/release/16.x/lld/MachO/Driver.cpp#L1021). Hence the commit that bumps the minimum version. Our current min runtime of `10.15` has been unsupported since September 2022, so I don't expect this bump to be controversial.

  Lastly, with the minimum runtime version bumped to 11.0, our current version of pre-compiled clang we use for macOS is too old to understand `-mmacosx-version-min=11.0` because it expects `=10.x`. So I've made the smallest possible bump (from 10.0.1 to 11.1.0) to a version that understands. This bump is arbitrary and unfortunate, but likely to be short-lived as we may end up replacing it with llvm+lld for v26 anyway. I've held off on bumping the SDK as I think that makes sense to do as part of the lld switch instead.

ACKs for top commit:
  hebasto:
    ACK 3df6070
  gruve-p:
    ACK bitcoin@3df6070
  fanquake:
    ACK 3df6070
  TheCharlatan:
    ACK 3df6070

Tree-SHA512: 0200ec4a3b88df33877ae82c15b5c04d745852550923f491a354b391cac65f88e4df116a40055c23a8cbcfcdfb9a376c6ae8fdd0e898e7b966bc213dcb5857cf