I2P connectivity

Given that BIP155 is now implemented, getting I2P support means being able to connect to the I2P network. Gossip of I2P addresses will work automatically without any further changes. I2P connectivity may be split in two:

1. Connecting to I2P addresses (make outgoing)

1.1. Using I2P SOCKS5 proxy

• Minimal changes to the source code - just add a new option -i2pproxy=, as SOCKS5 proxies are already supported by Bitcoin Core.
• Easy to configure for the user - just enable the SOCKS5 proxy on the I2P daemon.
• Implemented in https://github.com/bitcoin/bitcoin/pull/20254.

1.2. Using I2P client protocol SAM

• Moderate changes to the source code.
• Easy to configure for the user - just enable SAM on the I2P daemon.
• Not implemented yet.

2. Accepting connections from I2P peers (accept incoming)

2.1. Using I2P hidden service (statically configured inside the I2P daemon)

• Minimal changes to the source code - either none, or if we want to distinguish incoming I2P connections from others, then introduce -bind=addr:port=i2p.
• Tedious to configure for the user - a hidden service must be configured and managed in the I2P daemon.
• Implemented in https://github.com/bitcoin/bitcoin/pull/20254 without -bind=addr:port=i2p.

2.2. Using I2P client protocol SAM

• Moderate changes to the source code.
• Easy to configure for the user - just enable SAM on the I2P daemon.
• Not implemented yet.
• It will completely resolve the problem with distinguishing I2P connections from others because they are accepted via the SAM protocol.
• We will get the I2P address of the peer that is connecting to us. While I2P addresses are free/easy to generate, it is "impossible" to steal or impersonate as somebody else's address. This would make it possible to add trusted I2P nodes to -whitelist=.