SIGN IN SIGN UP

Merge bitcoin/bitcoin#34566: feature: Use different datadirs for different signets

feeb00af8cf361ba9d2f7de0334abf875b3103d9 cli: Add -signetchallenge info on RPC auth error (ekzyis)
c47ea370dc9f7a878e8269884b25204b8e6a3ec6 doc: Update documentation for signet datadir (ekzyis)
6f8c43f9efc601b26ae221e53bb3c354ea64b618 test: Add signet datadir tests (ekzyis)
9b37d42b23be096cc4cfb457f1022e443102b650 Use different datadirs for different signets (ekzyis)
6bdcae3f768b9e8da958ecbf46fa88b42df338f5 refactor: Import signet constant and helper from kernel/signet.h (ekzyis)

Pull request description:

  closes #27494

  This adds support for syncing multiple signets.

  Each custom signet is stored in a different datadir, using the network magic (message start) as the suffix.

  The default signet is always stored without a suffix for backward compatibility, even if the default challenge is provided explicitly via `-signetchallenge`.

  This builds upon #29838.

  For those already familiar with #29838, here are the differences between #29838 and this that are visible to the user:

  * The suffix does not use the first 4 bytes of hash160(challenge), but rather the network magic (message start) as mentioned in [#29838 (comment)](https://github.com/bitcoin/bitcoin/pull/29838#discussion_r1557976175) and [#34566 (comment)](https://github.com/bitcoin/bitcoin/pull/34566#issuecomment-4207665792).
  * If the default challenge is provided to `-signetchallenge`, [#29838](https://github.com/bitcoin/bitcoin/pull/29838) added a suffix to the datadir, whereas this PR does not. This includes backward compatibility when the default signet is used explicitly, not only implicitly, even though [the default signet consensus parameters aren't used in the explicit case](https://github.com/bitcoin/bitcoin/pull/29838#issuecomment-2742830552).[^1] A test was added for this case.

  [^1]: could be something for a follow-up PR, or maybe it's intentional to not mix explicit with implicit options?

  Unlike #29838, this PR does not update tests that didn't break (`rpc_bind.py`, `interface_bitcoin_cli.py`). I have found other tests where `datadir_path` is used in combination with `self.chain` (regexp: `datadir_path.*chain`). I considered it inconsistent to update some tests but not all of them. I've decided to not update all of them to keep the scope of this PR low until feedback. I can go through all tests in a follow-up PR to make sure they don't break when they are ever used with (custom) signet, however unlikely that might be.

  I have done some manual testing like this:

  <details>
  <summary>manual testing</summary>

  1. 'signet' directory is used, IBD:

  ```
  $ bitcoind -signet
  ```

  2. 'signet' directory is used, no IBD without `-addnode` (see [#29838 (comment)](https://github.com/bitcoin/bitcoin/pull/29838#issuecomment-2742830552)) or existing peers.dat:

  ```
  $ bitcoind -signet -signetchallenge=512103ad5e0edad18cb1f0fc0d28a3d4f1f3e445640337489abb10404f2d1e086be430210359ef5021964fe22d6f8e05b2463c9540ce96883fe3b278760f048f5189f2e6c452ae
  ```

  3. 'signet' directory is used

  ```
  $ bitcoind -conf="signet_default.conf"
  ```

  ```
  # signet_default.conf
  signet=1
  [signet]
  signetchallenge=512103ad5e0edad18cb1f0fc0d28a3d4f1f3e445640337489abb10404f2d1e086be430210359ef5021964fe22d6f8e05b2463c9540ce96883fe3b278760f048f5189f2e6c452ae
  ```

  4. 'signet_f6ac8550' directory is used:

  ```
  $ bitcoind -conf="signet_custom.conf"
  ```

  ```
  # signet_custom.conf
  signet=1
  [signet]
  signetchallenge=0014d4528367459d54e1545b0d0a677d2a7d71d648e0
  ```

  Tested RPC with `bitcoin-cli getblockchaininfo` with the same options (`-signet`, `-conf`, or `-signet -signetchallenge`)

  </details>

  I'm new to contributing to Bitcoin Core so it's entirely possible that I've missed something obvious.

ACKs for top commit:
  pinheadmz:
    ACK feeb00af8cf361ba9d2f7de0334abf875b3103d9
  ViniciusCestarii:
    Re-ACK feeb00af8cf361ba9d2f7de0334abf875b3103d9
  sedited:
    ACK feeb00af8cf361ba9d2f7de0334abf875b3103d9

Tree-SHA512: e06e5ad4f967f1c1b2d7cdfe3ad34ff4e09435012668889ea4fd817fec0fda153a3221c28846c06026dd573cbe0eec3872d569ed99614446528c5af890af2bbd
M
merge-script committed
d32a515fb0bbe7ce5be723ff37e532a8220bc3ce