Github-Pull: bitcoin#29192
Rebased-From: b45f1f5

Github-Pull: bitcoin#29192
Rebased-From: 6e873df

a7116c8 ci: Bump msan to llvm-18 (MarcoFalke)
05f69b3 ci, macos: Use `--break-system-packages` with Homebrew's python (Hennadii Stepanov)
603f036 ci: Add workaround for Homebrew's python link error (Hennadii Stepanov)
5d381cf serfloat: improve/simplify tests (Pieter Wuille)
f4be4d7 serfloat: do not test encode(bits)=bits anymore (Pieter Wuille)

Pull request description:

  Currently:
  * #29192
  * #29610
  * #29676

ACKs for top commit:
  stickies-v:
    ACK a7116c8 - all clean test backports

Tree-SHA512: f3508a2c20d336c8647ba16886859d6a070584c4739fc8b5cfce2041a0662794775fb0ce89c9bf848a29e70089bae05ad1c921bbe45afe3fd5cac2a5c6b76baf

6e873df serfloat: improve/simplify tests (Pieter Wuille)
b45f1f5 serfloat: do not test encode(bits)=bits anymore (Pieter Wuille)

Pull request description:

  Closes bitcoin#28941.

  Our current tests for serfloat verify two distinct properties:
  1. Whether they roundtrip `double`->`uint64_t`->`double` (excluding NaN values) on all systems.
  2. Whether on systems with a typical floating point unit that encoding matches the hardware representation, as before v22.0, we would dump the hardware representation directly to disk and we wanted to retain compatibility with that.

  bitcoin#28941 seems to show that the second property doesn't always hold, but just for "subnormal" numbers (below $2^{-1021}$). Since we don't care about encoding these numbers, we could exclude such subnormal numbers from the hardware-identical representation test, but this PR goes further and just drops the second property entirely, as I don't think we care about edge-case compatibility with pre-v22.0 code for fee_estimates.dat (the only place it is used).

ACKs for top commit:
  glozow:
    ACK 6e873df
  fanquake:
    ACK 6e873df - It's not as much of a priority, but I think we could still backport this.

Tree-SHA512: e18ceee0753a7ee7e999fdfa10b014dc5bb67b6ef79522a0f8c76b889adcfa785772fc26ed7559bcb5a09a9938e243bb54eedd9549bc59080a2c8090155e2267

6e873df serfloat: improve/simplify tests (Pieter Wuille)
b45f1f5 serfloat: do not test encode(bits)=bits anymore (Pieter Wuille)

Pull request description:

  Closes bitcoin#28941.

  Our current tests for serfloat verify two distinct properties:
  1. Whether they roundtrip `double`->`uint64_t`->`double` (excluding NaN values) on all systems.
  2. Whether on systems with a typical floating point unit that encoding matches the hardware representation, as before v22.0, we would dump the hardware representation directly to disk and we wanted to retain compatibility with that.

  bitcoin#28941 seems to show that the second property doesn't always hold, but just for "subnormal" numbers (below $2^{-1021}$). Since we don't care about encoding these numbers, we could exclude such subnormal numbers from the hardware-identical representation test, but this PR goes further and just drops the second property entirely, as I don't think we care about edge-case compatibility with pre-v22.0 code for fee_estimates.dat (the only place it is used).

ACKs for top commit:
  glozow:
    ACK 6e873df
  fanquake:
    ACK 6e873df - It's not as much of a priority, but I think we could still backport this.

Tree-SHA512: e18ceee0753a7ee7e999fdfa10b014dc5bb67b6ef79522a0f8c76b889adcfa785772fc26ed7559bcb5a09a9938e243bb54eedd9549bc59080a2c8090155e2267

6e873df serfloat: improve/simplify tests (Pieter Wuille)
b45f1f5 serfloat: do not test encode(bits)=bits anymore (Pieter Wuille)

Pull request description:

  Closes bitcoin#28941.

  Our current tests for serfloat verify two distinct properties:
  1. Whether they roundtrip `double`->`uint64_t`->`double` (excluding NaN values) on all systems.
  2. Whether on systems with a typical floating point unit that encoding matches the hardware representation, as before v22.0, we would dump the hardware representation directly to disk and we wanted to retain compatibility with that.

  bitcoin#28941 seems to show that the second property doesn't always hold, but just for "subnormal" numbers (below $2^{-1021}$). Since we don't care about encoding these numbers, we could exclude such subnormal numbers from the hardware-identical representation test, but this PR goes further and just drops the second property entirely, as I don't think we care about edge-case compatibility with pre-v22.0 code for fee_estimates.dat (the only place it is used).

ACKs for top commit:
  glozow:
    ACK 6e873df
  fanquake:
    ACK 6e873df - It's not as much of a priority, but I think we could still backport this.

Tree-SHA512: e18ceee0753a7ee7e999fdfa10b014dc5bb67b6ef79522a0f8c76b889adcfa785772fc26ed7559bcb5a09a9938e243bb54eedd9549bc59080a2c8090155e2267

6e873df serfloat: improve/simplify tests (Pieter Wuille)
b45f1f5 serfloat: do not test encode(bits)=bits anymore (Pieter Wuille)

Pull request description:

  Closes bitcoin#28941.

  Our current tests for serfloat verify two distinct properties:
  1. Whether they roundtrip `double`->`uint64_t`->`double` (excluding NaN values) on all systems.
  2. Whether on systems with a typical floating point unit that encoding matches the hardware representation, as before v22.0, we would dump the hardware representation directly to disk and we wanted to retain compatibility with that.

  bitcoin#28941 seems to show that the second property doesn't always hold, but just for "subnormal" numbers (below $2^{-1021}$). Since we don't care about encoding these numbers, we could exclude such subnormal numbers from the hardware-identical representation test, but this PR goes further and just drops the second property entirely, as I don't think we care about edge-case compatibility with pre-v22.0 code for fee_estimates.dat (the only place it is used).

ACKs for top commit:
  glozow:
    ACK 6e873df
  fanquake:
    ACK 6e873df - It's not as much of a priority, but I think we could still backport this.

Tree-SHA512: e18ceee0753a7ee7e999fdfa10b014dc5bb67b6ef79522a0f8c76b889adcfa785772fc26ed7559bcb5a09a9938e243bb54eedd9549bc59080a2c8090155e2267

6e873df serfloat: improve/simplify tests (Pieter Wuille)
b45f1f5 serfloat: do not test encode(bits)=bits anymore (Pieter Wuille)

Pull request description:

  Closes bitcoin#28941.

  Our current tests for serfloat verify two distinct properties:
  1. Whether they roundtrip `double`->`uint64_t`->`double` (excluding NaN values) on all systems.
  2. Whether on systems with a typical floating point unit that encoding matches the hardware representation, as before v22.0, we would dump the hardware representation directly to disk and we wanted to retain compatibility with that.

  bitcoin#28941 seems to show that the second property doesn't always hold, but just for "subnormal" numbers (below $2^{-1021}$). Since we don't care about encoding these numbers, we could exclude such subnormal numbers from the hardware-identical representation test, but this PR goes further and just drops the second property entirely, as I don't think we care about edge-case compatibility with pre-v22.0 code for fee_estimates.dat (the only place it is used).

ACKs for top commit:
  glozow:
    ACK 6e873df
  fanquake:
    ACK 6e873df - It's not as much of a priority, but I think we could still backport this.

Tree-SHA512: e18ceee0753a7ee7e999fdfa10b014dc5bb67b6ef79522a0f8c76b889adcfa785772fc26ed7559bcb5a09a9938e243bb54eedd9549bc59080a2c8090155e2267

6e873df serfloat: improve/simplify tests (Pieter Wuille)
b45f1f5 serfloat: do not test encode(bits)=bits anymore (Pieter Wuille)

Pull request description:

  Closes bitcoin#28941.

  Our current tests for serfloat verify two distinct properties:
  1. Whether they roundtrip `double`->`uint64_t`->`double` (excluding NaN values) on all systems.
  2. Whether on systems with a typical floating point unit that encoding matches the hardware representation, as before v22.0, we would dump the hardware representation directly to disk and we wanted to retain compatibility with that.

  bitcoin#28941 seems to show that the second property doesn't always hold, but just for "subnormal" numbers (below $2^{-1021}$). Since we don't care about encoding these numbers, we could exclude such subnormal numbers from the hardware-identical representation test, but this PR goes further and just drops the second property entirely, as I don't think we care about edge-case compatibility with pre-v22.0 code for fee_estimates.dat (the only place it is used).

ACKs for top commit:
  glozow:
    ACK 6e873df
  fanquake:
    ACK 6e873df - It's not as much of a priority, but I think we could still backport this.

Tree-SHA512: e18ceee0753a7ee7e999fdfa10b014dc5bb67b6ef79522a0f8c76b889adcfa785772fc26ed7559bcb5a09a9938e243bb54eedd9549bc59080a2c8090155e2267

fbc0bce Merge bitcoin#29665: build, depends: Fix `libmultiprocess` cross-compilation (fanquake)
59a2145 Merge bitcoin#29747: depends: fix mingw-w64 Qt DEBUG=1 build (fanquake)
bdb2fa6 Merge bitcoin#29671: index: avoid "failed to commit" errors on initialization (Ava Chow)
65377ea Merge bitcoin#29192: Weaken serfloat tests (fanquake)
4122404 Merge bitcoin#28891: test: fix `AddNode` unit test failure on OpenBSD (fanquake)
812ef53 Merge bitcoin#25677: refactor: make active_chain_tip a reference (MacroFake)
34e12fa Merge bitcoin#24564: doc: Clarify that CheckSequenceLocksAtTip is a validation function (glozow)
d529751 Merge bitcoin#24788: doc: Add gpg key import instructions for Windows (fanquake)
61bae78 Merge bitcoin#24784: refactor: deduplicate integer serialization in RollingBloom benchmark (MarcoFalke)

Pull request description:

  ## Issue being fixed or feature implemented
  Trivial backports

  ## What was done?

  ## How Has This Been Tested?
  built locally

  ## Breaking Changes

  ## Checklist:
    _Go over all the following points, and put an `x` in all the boxes that apply._
  - [ ] I have performed a self-review of my own code
  - [ ] I have commented my code, particularly in hard-to-understand areas
  - [ ] I have added or updated relevant unit/integration/functional/e2e tests
  - [ ] I have made corresponding changes to the documentation
  - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_

ACKs for top commit:
  UdjinM6:
    utACK fbc0bce

Tree-SHA512: 731f70b747712810d4f74fe64a90139b02ddb62e9ac260705fa2588595feb19bd6e5ffed521fd878bacaab0015683e582fed19ed1855c3e955f93cd223862a17