fa25f43 p2p: Remove BIP61 reject messages (MarcoFalke)

Pull request description:

  Reject messages (BIP 61) appear in the following settings:

  * Parsing of reject messages (in case `-debug=net` is set, off by default). This has only been used for a single `LogPrint` call for several releases now. Such logging is completely meaningless to us and should thus be removed.

  * The sending of reject messages (in case `-enablebip61` is set, off by default). This can be used to debug a node that is under our control. Instead of hacking this debugging into the p2p protocol, it could be more easily achieved by parsing the debug log. (Use `-printtoconsole` to have it as stream, or read from the `debug.log` file like our python function `assert_debug_log` in the test framework does)

  Having to maintain all of this logic and code to accommodate debugging, which can be achieved by other means a lot easier, is a burden. It makes review on net processing changes a lot harder, since the reject message logic has to be carried around without introducing any errors or DOS vectors.

ACKs for top commit:
  jnewbery:
    utACK fa25f43
  laanwj:
    I'm still not 100% convinced that I like getting rid of BIP61 conceptually, but apparently everyone wants it, code review ACK fa25f43.
  ryanofsky:
    Code review ACK fa25f43

Tree-SHA512: daf55254202925e56be3d6cfb3c1c804e7a82cecb1dd1e5bd7b472bae989fd68ac4f21ec53fc46751353056fd645f7f877bebcb0b40920257991423a3d99e0be

fa25f43 p2p: Remove BIP61 reject messages (MarcoFalke)

Pull request description:

  Reject messages (BIP 61) appear in the following settings:

  * Parsing of reject messages (in case `-debug=net` is set, off by default). This has only been used for a single `LogPrint` call for several releases now. Such logging is completely meaningless to us and should thus be removed.

  * The sending of reject messages (in case `-enablebip61` is set, off by default). This can be used to debug a node that is under our control. Instead of hacking this debugging into the p2p protocol, it could be more easily achieved by parsing the debug log. (Use `-printtoconsole` to have it as stream, or read from the `debug.log` file like our python function `assert_debug_log` in the test framework does)

  Having to maintain all of this logic and code to accommodate debugging, which can be achieved by other means a lot easier, is a burden. It makes review on net processing changes a lot harder, since the reject message logic has to be carried around without introducing any errors or DOS vectors.

ACKs for top commit:
  jnewbery:
    utACK fa25f43
  laanwj:
    I'm still not 100% convinced that I like getting rid of BIP61 conceptually, but apparently everyone wants it, code review ACK fa25f43.
  ryanofsky:
    Code review ACK fa25f43

Tree-SHA512: daf55254202925e56be3d6cfb3c1c804e7a82cecb1dd1e5bd7b472bae989fd68ac4f21ec53fc46751353056fd645f7f877bebcb0b40920257991423a3d99e0be

b1b0cfe test: Remove REJECT message code (Hennadii Stepanov)

Pull request description:

  We no longer use REJECT p2p message:
  - bitcoin#15437
  - bitcoin#17004

ACKs for top commit:
  theStack:
    ACK bitcoin@b1b0cfe (nice dead code find)

Tree-SHA512: 0a662b282e921c3991aeb15f54d077837f1ef20bc2e3b0b35117bb97a21d1bd1c3e21458e5c18ba0ca02030d559e3e8e74dbd3d3e2b46dbe7bede550948c3b55

Summary:
>Reject messages (BIP 61) appear in the following settings:
>   - Parsing of reject messages (in case -debug=net is set, off by default). This has only been used for a single LogPrint call for several releases now. Such logging is completely meaningless to us and should thus be removed.
>   - The sending of reject messages (in case -enablebip61 is set, off by default). This can be used to debug a node that is under our control. Instead of hacking this debugging into the p2p protocol, it could be more easily achieved by parsing the debug log. (Use -printtoconsole to have it as stream, or read from the debug.log file like our python function assert_debug_log in the test framework does)
>
> Having to maintain all of this logic and code to accommodate debugging, which can be achieved by other means a lot easier, is a burden. It makes review on net processing changes a lot harder, since the reject message logic has to be carried around without introducing any errors or DOS vectors.

Backport of Core [[bitcoin/bitcoin#15437 | PR15437]]

Test Plan: `ninja && ninja check-all`

Reviewers: O1 Bitcoin ABC, #bitcoin_abc, deadalnix

Reviewed By: O1 Bitcoin ABC, #bitcoin_abc, deadalnix

Subscribers: deadalnix

Differential Revision: https://reviews.bitcoinabc.org/D7981

…ic + BIP61 removal.

8e9f2bc Net_processing: Minimize tier two messages search time and improve code. (furszy)
56a78fc Clean few compiler warnings in blockassembler, validation, rpcwallet and evo_deterministicmns_tests files. (furszy)
c398797 Refactor: Name GetDataMsg enum and replace ppszTypeName array for direct GetCommand call. (furszy)
f99c5ed Move-only: IsTransactionInChain functions moved inside zpivchain.cpp and made static as them are only used there. (furszy)
2e1af2b Remove IsBlockHashInChain function. Only used inside IsTransactionInChain. (furszy)
38d49ea Document 'DisconnectOldProtocol' call rationale in block processing. (furszy)
4f62c04 Remove now unneeded `fAccepted` flag from ProcessNewBlock. (furszy)
0d4ba29 Move block spam filter check to BlockChecked (furszy)
bd85440 Refactor: get rid off the error prone CValidationState argument in ProcessNewBlock. (furszy)
22b1757 validation: Proper validation state set for "out of order" check in CheckBlock. (furszy)
9606474 net_processing: Clean CheckBlockSpam code and add proper cs_main locks in State() call and mapBlockIndex access. (furszy)
e6d2bd6 net_processing: Remove duplicate, and wrong, peer misbehaving due an invalid arriving block. (furszy)
6a5df01 p2p: Remove BIP61 reject messages (furszy)

Pull request description:

  Continuation of #2463. Another error prone topic.

  Essentially focused in the following points:
  * Remove duplicate and incorrect peer misbehaving:
  -1) The peer misbehaving score set for an invalid arriving block is being performed inside `PeerLogicValidation::BlockChecked`.
  -2) The `CValidationState` param in `ProcessNewBlock` does not return the error nor the invalidity reason if the block is marked invalid during the activate best chain process (block connection), an empty `CValidationState` is set. The `BlockChecked` signal is used instead to notify the block invalidity reason.

  * Get rid off `CValidationState` param in `ProcessNewBlock` and use only `BlockChecked` (own version of ae22357)
  * Removal of BIP61 (bitcoin#15437 and bitcoin#18609).
  -- BIP61 could be disabled first by default before its removal like upstream did (or moved to its own standalone PR), but.. i don't think that worth to continue maintaining it, most likely no one is using it and if someone is actually using it, isn't good to have any piece of software depending on it. --
  * Move block spam filter check to `BlockChecked`. Following the same peer-processing-logic / block-connection-logic division. Improves the spam protection as now blocks rejected during the connection process are going to pass through the spam filter check as well (before, only blocks rejected during `AcceptBlock` were passing through it).
  Plus, this improvement let me do some further cleanup and remove the extra `fAccepted` flag from `ProcessNewBlock`.
  * Create `GetDataMsg` enum and replace `ppszTypeName` array for direct `GetCommand` call.
  The array was duplicated with the `NetMsgType` constants

ACKs for top commit:
  random-zebra:
    ACK 8e9f2bc

Tree-SHA512: 362219e995c857ac9ad45119d0cad24b1afcb94c807d5af60d7008dd985c3b324b5f2938d60890f89d610d214f69f6a6d5ef12d2ce4e6016480ad984d00706c4