net: disconnect evicted inbound peers immediately #35256

Fixes #27843.

CreateNodeFromAcceptedSocket() enforces the inbound connection limit by calling AttemptToEvictConnection() when the inbound slots are full. The selected peer was previously only marked fDisconnect, leaving socket closure and removal from m_nodes to ThreadSocketHandler().

That works for TCP accepts, which run in the socket handler loop, but I2P accepts run in ThreadI2PAcceptIncoming(). During an I2P inbound burst, the accept thread can add replacement peers before the socket handler drains the evicted ones, temporarily exceeding -maxconnections.

This change removes an evicted inbound peer from m_nodes, closes its socket, and queues it for deferred deletion immediately from AttemptToEvictConnection(). m_nodes_disconnected is now guarded by m_nodes_mutex, since the eviction path can append to it outside the socket handler thread.

A regression test fills the inbound slots, accepts one more inbound connection, and checks that the replacement does not grow m_nodes.

Test

cmake --build build --target test_bitcoin
build/bin/test_bitcoin --run_test=net_peer_connection_tests/inbound_eviction_removes_node_immediately
build/bin/test_bitcoin --run_test=net_peer_connection_tests
build/bin/test_bitcoin --run_test=net_peer_eviction_tests
build/bin/test_bitcoin --run_test=i2p_tests

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35256.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Thx, but LLM output is not accepted if the author can not properly explain, test or could have written the change themselves.

The bottleneck in this project has always been review and testing, not writing code. Development here is intentionally conservative and slow, and reviewer attention is the scarcest resource we have. LLMs have made this worse, anyone can now prompt them and post their output as PRs. There is an infinite amount plausible looking "improvements" for LLMs to suggest and work on.

Unless we fully trust LLMs to both write and review code, humans still have to spend time understanding the proposed changes, which incurs a non-zero cost for every opened PR.

I understand that contributing to this project can be intimidating, and using LLMs may seem tempting, but it really creates more issues for this project than it solves. The best way to help this project, is to review and test changes. You can use LLMs for this, but you shouldn't solely rely on them, or just post their output.

I'm not asking you to close this PR. I am asking you to reconsider whether it's something you genuinely think the project should pursue, independent of what your LLM suggested.

Closing for now.