8ebfff0f88 doc: add send RPC release note (Sjors Provoost)
5884f5a4fa wallet: remove experimental warning from send RPCs (Sjors Provoost)
Pull request description:
The `send` RPC was introduced in v21 an initially marked experimental. The `sendall` RPC was added in v24, based on `send` and also marked experimental.
I'm not aware of any proposed breaking changes, except #35433 which follows the regular deprecation flow.
Time to mark them as no longer experimental.
ACKs for top commit:
w0xlt:
ACK 8ebfff0f88
achow101:
ACK 8ebfff0f88
polespinasa:
ACK 8ebfff0f88
pablomartin4btc:
ACK 8ebfff0f88
Tree-SHA512: beb5321adaf871157bda396c8e5740daff95ffe342416914340ae4197accebe60236032d1329876b42405437b99f59079a56ec1e5ac592b753031ba2ebd36cfb
58560c281d ci: remove some packages from Chimera job (fanquake)
Pull request description:
This job doesn't build QT, so drop `ninja` and `xz`.
With libevent removed, and no Qt build, we can also drop `pkgconf`.
ACKs for top commit:
sedited:
ACK 58560c281d
hebasto:
ACK 58560c281d.
Tree-SHA512: 4537c8c77334637ea177321d95ad39ee103ab0080e8331f9fe9efb92a3bb4dc00fb59d2e250fd43c267c05f0a2b98e779949ff40723633c2f2bff345fa554a31
9e6546c517 test: raise reindex mining RPC timeout (Lőrinc)
Pull request description:
**Problem:** I often hit a timeout in `feature_reindex.py` when running functional tests locally in parallel in debug mode (especially on battery or in power-saving mode).
**Fix:** Increase the test-local RPC timeout for the reindex mining setup.
ACKs for top commit:
mercie-ux:
ACK 9e6546c517
sedited:
ACK 9e6546c517
Tree-SHA512: d3541dd6752f943921a030393b00e684b3b5d00b93aa0b2b1f85c017698bdfe2216d7f5441bb7dd5f153453385e4df6f9cc8055589e57bca83fa48f0b7de4252
0cdd817a82 add release note (Pol Espinasa)
517d37ce3e test: tests wallet migration with load_wallet disabled (Pol Espinasa)
b98dd63da7 rpc: Add load_wallet argument to migratewallet RPC (Pol Espinasa)
4acd063ba6 wallet: make loading the wallet after migrating optional (Pol Espinasa)
97d08d62ba refactor: store wallet names to MigrationResult (Pol Espinasa)
Pull request description:
This PR is motivated by this [Stack Exchange question](https://bitcoin.stackexchange.com/questions/130713/bitcoin-core-quickest-method-legacy-descriptor-wallet-migration).
Long story short, someone who has a node pruned before his legacy wallet birthday, is unable to migrate the wallet as it is not possible to load it.
Loading is not necessary for migration, and migrating without wanting to use the wallet in that node is a valid use-case.
This PR adds a new RPC argument to `migratewallet` that allow the user disabling the wallet loading.
Second commits adds tests for it.
Follow-up: Add an option to the GUI to not load the wallet after migrating.
ACKs for top commit:
achow101:
ACK 0cdd817a82
w0xlt:
ACK 0cdd817a82
pablomartin4btc:
ACK 0cdd817a82
Tree-SHA512: 8389599e63603b1a532e1bfba0b6c652653386c001f5a881bd49843302b74ff4dbaa4131b5b377c24f483d42e0e70a92b96f760244e3c2e2b44ce08cd04ca1e0
703a671fbc fuzz: compact coins view db during fuzzing (Lőrinc)
0868c85fd5 refactor: rename async coin compaction (Lőrinc)
Pull request description:
**Problem:** #35465 added async chainstate compaction, but the `coins_view_db` fuzz target did not exercise scheduling compaction alongside ordinary coins view operations.
The async wrapper also shared the `CompactFull()` name with the blocking `CDBWrapper` primitive.
**Fix:** Rename the coins DB wrapper to `CompactFullAsync()` and let `coins_view_db` randomly schedule it under `cs_main` (like in production).
The fuzz operation only starts compaction and any running job is joined by the `CCoinsViewDB` destructor at the end of the fuzz input.
ACKs for top commit:
sedited:
ACK 703a671fbc
andrewtoth:
ACK 703a671fbc
Tree-SHA512: 9854c3acbaace795155e7469cb10938fbd872726cbb8a4b4ef71d6d352d00824498747215aee1b237e64452eae2e690a3f7d7daa6b6b0030e75a6f2ccc0802fb
abc33ff043 test: announce field must be 0 or 1 in sendcmpct (brunoerg)
2d0dce0af5 net_processing: fix BIP152 first integer interpretation (brunoerg)
Pull request description:
Fixes#35542
According to the BIP152, the first integer in `sendcmpct` message shall be interpreted as a boolean (and MUST have a value of either 1 or 0). We currently correctly interpret it as boolean, however, we accept any value >=1 and treat it as `true`, deviating from the specification. This PR fixes it.
ACKs for top commit:
edilmedeiros:
utACK abc33ff043
davidgumberg:
crACK abc33ff043 Seems reasonable to comply with BIP152 strictly, test looks good as well.
Sjors:
ACK abc33ff043
jonatack:
re-ACK abc33ff043
achow101:
ACK abc33ff043
w0xlt:
ACK abc33ff043
Tree-SHA512: 77fed86d4de81f7c35ff002b6e1b2a90882ea55f159075da4d34a619d1075f625fca34f929cdd981f1b2eb06f76b64f42cda46502dcd1b4a634c690b0882ec7c
Exercise `CCoinsViewDB::CompactFullAsync()` from the `coins_view_db` fuzz target so the new chainstate compaction wrapper can run concurrently with ordinary coins view operations.
The fuzz operation only schedules compaction, matching production; outstanding work is waited for by the `CCoinsViewDB` destructor at the end of the fuzz input.
Rename the `CCoinsViewDB` async compaction wrapper to `CompactFullAsync()` so it is distinct from the blocking `CDBWrapper::CompactFull()` primitive it calls.
b847626562 test: refresh MiniWallet after node restart (Sjors Provoost)
f4e643cb15 test: merge mining options in package feerate check (Sjors Provoost)
280ce6a0ae miner: ensure block_max_weight is flattened before limit checks (Sjors Provoost)
65bd3164fb mining: clarify test_block_validity comment (Sjors Provoost)
978e7216e6 test: use shared default_ipc_timeout (Sjors Provoost)
Pull request description:
This implement the suggested followups from #33966. Each commit links to the original comment.
The most important change is the extra asserts added in `miner: ensure block_max_weight is flattened before limit checks`.
ACKs for top commit:
achow101:
ACK b847626562
enirox001:
tACK b847626562
sedited:
ACK b847626562
w0xlt:
ACK b847626562
Tree-SHA512: 47678eaed604228269bd892ccf8ff58804745bbc7675b4a93528da9a9292a2eb1e0562cdb8341edac77178563420885b48282bb9e5c2b997b28f2fc64ceeff3d
2fe34808fa wallet: reject sendtoaddress and sendmany for external signers (Sjors Provoost)
bd5a32f7db doc: add taproot descriptor to getdescriptors example (woltx)
7131c82937 doc: clarify which commands receive --chain, --fingerprint and --stdin (woltx)
4fdd4d8d29 doc: replace stale signtransaction wording with current signtx flow (woltx)
fab92257fe doc, rpc: document enumerate model field and fingerprint deduplication (woltx)
Pull request description:
This PR aligns the external signer documentation with current behavior, and makes one previously implicit behavior explicit.
Per review feedback, each commit fixes a limited set of issues:
* **doc, rpc: document enumerate model field and fingerprint deduplication** — the `enumerate` response uses the optional `model` field, which Bitcoin Core maps to the `name` field of the `enumeratesigners` RPC result. Duplicate fingerprints are skipped, and wallet operations require exactly one connected signer.
* **doc: replace stale signtransaction wording with current signtx flow** — spending from an external signer wallet uses `send`/`sendall` (and `bumpfee` for fee-bumping), which invoke `<cmd> --stdin` and pass the `signtx` subcommand and PSBT over stdin.
* **doc: clarify which commands receive --chain, --fingerprint and --stdin** — mark `--chain` and `--fingerprint` as required except for `enumerate`, keep `--stdin` required for protocol flexibility, and match the order and form of the actual invocations in the usage examples.
* **doc: add taproot descriptor to getdescriptors example** — show the BIP86 `tr()` descriptor alongside the other address types.
* **wallet: reject sendtoaddress and sendmany for external signers** — return a specific error instead of the misleading "Private keys are disabled for this wallet", with functional test coverage. Cherry-picked from #33112 (thanks Sjors).
How the documentation went stale:
* The `enumerate` example has shown a `name` field since external signer support landed in #16546, but the implementation has always read `model`.
* `sendtoaddress`/`sendmany` external signer support was effectively precluded by #21201, which was merged a few days before #16546, so the interaction was missed in review and the documented `signtransaction` flow never existed in this form.
* Fingerprint deduplication was added in #35251.
* The documentation was last updated in #33765.
ACKs for top commit:
Sjors:
ACK 2fe34808fa
optout21:
ACK 2fe34808fa
naiyoma:
ACK 2fe34808fa
Tree-SHA512: 86859d2f81ac337f3b4b6578c6ee0151ffb76b8374dfa58e28e00ce4eb69dc200cd6bd2d0a99f73d0475c3824d6ac1cb9e2542b119ca124dd835132dc95cd023
d6359937bf validation: check invariants when inserting into m_blocks_unlinked (stratospher)
0852925bd8 test/doc: remove misleading comment and improve tests (stratospher)
ca4a380281 test: add coverage for UB caused by FindMostWorkChain (stratospher)
c787b3b99b validation: avoid duplicates in m_blocks_unlinked (stratospher)
Pull request description:
This is joint work with @ mzumsande.
note: this requires a pruned node with deep reorgs to trigger. still it breaks assumptions in the codebase and is good to fix. A similar UB was fixed in https://github.com/bitcoin/bitcoin/pull/34521.
This PR prevents duplicate insertions into `m_blocks_unlinked` in `FindMostWorkChain`. There are 3 ways to insert into `m_blocks_unlinked`:
1. `LoadBlockIndex` - not problematic, as each block index is processed only once.
2. `ReceivedBlockTransactions` - not problematic, as this is usually only called once per block when it is first accepted in `AcceptBlock`. in the rare case it’s triggered again after pruning, the block would have been removed from `m_blocks_unlinked` when it was initially pruned, so duplicates still can’t arise.
3. `FindMostWorkChain` - problematic when multiple candidate tips share common chains of ancestors, traversals from each tip to the fork point may insert duplicate (`pprev`, `pindex`) entries for blocks whose parents have been pruned.
When the missing parent is later received and `ReceivedBlockTransactions` processes `m_blocks_unlinked`, the same entry may be processed multiple times. This can result in the block being re-added to `setBlockIndexCandidates` with a modified `nSequenceId`, violating its ordering invariants and leading to undefined behavior. So avoid duplicate insertions into `m_blocks_unlinked` in `FindMostWorkChain`.
### how to test:
use the updated `feature_pruning.py` which adds coverage for this scenario.
- on master: the test (with the below diff) fails since `nSequenceId` is being modified for an entry in `setBlockIndexCandidates`
- on this branch: the test (with the below diff) passes
```diff --git a/src/validation.cpp b/src/validation.cpp
--- a/src/validation.cpp
+++ b/src/validation.cpp
@@ -3814,6 +3814,12 @@ void ChainstateManager::ReceivedBlockTransactions(const CBlock& block, CBlockInd
pindex->nHeight, pindex->m_chain_tx_count, prev_tx_sum(*pindex), CLIENT_NAME, FormatFullVersion(), CLIENT_BUGREPORT);
}
pindex->m_chain_tx_count = prev_tx_sum(*pindex);
+ for (const auto& c : m_chainstates) {
+ if (c->setBlockIndexCandidates.contains(pindex)) {
+ LogInfo("### pindex UB = %s", pindex);
+ assert(false);
+ }
+ }
pindex->nSequenceId = nBlockSequenceId++;
for (const auto& c : m_chainstates) {
c->TryAddBlockIndexCandidate(pindex);
```
ACKs for top commit:
sedited:
Re-ACK d6359937bf
marcofleon:
crACK d6359937bf
stringintech:
ACK d6359937bf
mzumsande:
Sure - Code Review ACK [d635993](d6359937bf)
Tree-SHA512: bb21adc2d92fe1865bbbcebf775a850ca3eccac6fe83d7bca10b78eee4c0abf782e44fa0ddfec9d9a70f42fa40bdc49b68a1d1b4905cdc371ba29117d3120619
Loading the wallet after migrating is not a necessary step.
By making it optional pruned nodes can also migrate legacy wallets.
Also remove the migrated wallet from the list of wallets to load on startup.
b552f1713a ci: use warp docker buildkit cache (will)
Pull request description:
This was inadvertently broken in #35441 when we dropped the runners job. Unfortunately GHA seems to continue just fine when this field is empty, so it wasn't noticed at runtime.
ACKs for top commit:
m3dwards:
ACK b552f1713a
Tree-SHA512: 0bc61b42e94b0a73ef6026dea3dce27fdea611218936e585b5232fde358b4fab4728d59338b86c75affec80c11b6f1fada56ffb785999fabae0b01becb41268d
48df0939e7 fuzz: Remove unnecessary thread pool mutexes (marcofleon)
a4c3b003f8 fuzz: Speed up dbwrapper_concurrent_reads harness (marcofleon)
Pull request description:
Limiting how many read queries each worker executes significantly speeds up this test, especially when running with sanitizers. This still builds the full query list, and then takes the first 128/2000 after each worker shuffles it. I think that keeps some more operation diversity vs just lowering the query max directly. It also allowed me to reuse and test against a corpus I already had. Let me know if I'm wrong, but I don't think this test needs every worker to execute an identical query list to be effective.
This PR also reverts the `num_entries` max from 3000 back to 5000, as that didn't have much effect on input speed and restores a bit of lost coverage.
Lastly, as https://github.com/bitcoin/bitcoin/pull/35455#discussion_r3394357385 points out, remove the unnecessary `Mutex` from `StartReadPoolIfNeeded()`. Fuzz targets are entered sequentially within a process and parallel fuzzing uses separate processes/forks, so a mutex to prevent two in-process callers from racing to start the pool isn't needed.
ACKs for top commit:
sedited:
ACK 48df0939e7
brunoerg:
ACK 48df0939e7
Tree-SHA512: 24c35e13fa26790b36e5190283b78dd8511165d576841cb701f541a36c5b7c0a73f9bc265e71598a879fa1df9a9438e7841736f72b967214196fa6fe68569eff
61020b36c5 doc: add release note for #35182 replace libevent HTTP server (Matthew Zipkin)
39e9099da5 logging: deprecate libevent category (Matthew Zipkin)
8c1eea0777 http: remove libevent usage from this subsystem (Matthew Zipkin)
e427c227fa fuzz: switch http_libevent::HTTPRequest to http_bitcoin::HTTPRequest (Matthew Zipkin)
21c7542cf8 http: switch servers from libevent to bitcoin (Matthew Zipkin)
cbb8d1fb33 HTTPServer: disconnect after idle timeout (-rpcservertimeout) (Matthew Zipkin)
e5f242eef3 HTTPServer: implement control methods to match legacy API (Matthew Zipkin)
2ca645c2e4 refactor: split HTTPBindAddresses into config parse and libevent setup (Matthew Zipkin)
fec6b6bca8 refactor: split http_request_cb into libevent callback and dispatch (Matthew Zipkin)
f946ff5a0b Add helper methods to HTTPRequest to match original API (Matthew Zipkin)
dd11b5e01b define HTTP request methods at module level outside of class (Matthew Zipkin)
7ee7df988e HTTPServer: use a queue to pipeline requests from each connected client (Matthew Zipkin)
5ef1b80a09 Allow http workers to send data optimistically as an optimization (Matthew Zipkin)
a69bb9e1e6 HTTPServer: disconnect clients (Matthew Zipkin)
cdf71998e5 HTTPServer: compose and send replies to connected clients (Matthew Zipkin)
6734bcdeff HTTPserver: support "chunked" Transfer-Encoding (Matthew Zipkin)
80e1cfe5a2 HTTPServer: read requests from connected clients (Matthew Zipkin)
3c5226ab96 HTTPServer: start an I/O loop in a new thread and accept connections (Matthew Zipkin)
4ef4ebdc0c http: Introduce HTTPRemoteClient class (Matthew Zipkin)
a85286c5c7 HTTPServer: generate sequential Ids for each newly accepted connection (Matthew Zipkin)
5a3aa1af28 HTTPServer: implement and test AcceptConnection() (Matthew Zipkin)
f5bc018948 http: Introduce HTTPServer class and implement binding to listening socket (Matthew Zipkin)
9463e98781 http: Implement HTTPRequest class (Matthew Zipkin)
ad50aa4a0f http: Implement HTTPResponse class (Matthew Zipkin)
68b5d289d1 http: Implement HTTPHeaders class (Matthew Zipkin)
89c54ae4cb http: enclose libevent-dependent code in a namespace (Matthew Zipkin)
5aa3629b48 util/string: LineReader should only trim \r or \r\n (Matthew Zipkin)
0cdbb191b5 util/string: use string_view in LineReader (Matthew Zipkin)
881d4b6c75 test: cover common HTTP attacks and common malformed requests (Matthew Zipkin)
Pull request description:
Continued from #32061.
This is a major component of [removing libevent as a dependency of the project](https://github.com/bitcoin/bitcoin/issues/31194), by replacing the HTTP server used for RPC and REST with one implemented entirely within the Bitcoin Core codebase. The new `HTTPServer` class runs its own I/O thread, handling socket connections with code based on #30988, but tailored specifically for HTTP.
Commit strategy:
- Isolate the existing libevent-based HTTP server in a namespace `http_libevent`
- Implement HTTP in a new namespace `http_bitcoin` (classes like `HTTPRequest`, `HTTPClient`, etc...)
- Switch bitcoind from the libevent server to the new server
- Clean up (delete `http_libevent`)
## RFC compliance
I ran https://www.http-probe.com/ against v31.0 release and this PR branch at commit ddefe4263b42. While both HTTP servers failed several of the very picky compliance tests, the only differences in test results between the two branches is an *improvement* in the test results of the PR branch.
Raw test results:
- [v31.0](https://gist.github.com/pinheadmz/bb0debd49e8556417e9f0072a4463b31)
- [PR Branch](https://gist.github.com/pinheadmz/7267cdd90ff9deee8034788b5d1148de)
Test result comparison:
- https://gist.github.com/pinheadmz/08a5814345e02bf1ac1304e8e5b163a1
- Summary: `Changed results: 33 (Fail→Pass: 32, Pass→Fail: 0, other: 1)`
## Fuzz testing
### libfuzzer
- 4 days x8 cores at ddefe4263b
- generated corpus: https://github.com/pinheadmz/qa-assets/tree/httprequest-pr35182-ddefe4263b
- coverage report: https://thebitcoinblockclock.com/demo/libfuzzer_pr35182_ddefe4263b/index.html
### fuzzamoto
- 4 days x8 cores at commit ddefe4263b with a [patched fuzzer](https://github.com/pinheadmz/fuzzamoto/tree/http)
- coverage report: https://thebitcoinblockclock.com/demo/fuzzamoto_pr35182_ddefe4263b/coverage/bitcoin/index.html
## Integration testing:
I am testing the new HTTP server by forking projects that integrate with bitcoin via HTTP and running their integration tests with bitcoind built from this branch (on Github actions). I will continue adding integrations over time, and re-running these CI tests as this branch gets rebased:
- ✅ [lnd](https://github.com/pinheadmz/lnd/pull/7) master at `f21262dd6` tested with this branch at `ddefe4263b`
- ✅ [NodeJS `rpc-bitcoin`](https://github.com/pinheadmz/rpc-bitcoin/pull/4) master at `eb0c5da7d1094629cb4a381733cb01c9bb9a4608` tested with this branch at `ddefe4263b`
- ✅ [electrs](https://github.com/pinheadmz/electrs/pull/5) master at `d81dc35ae8f71c22b96cf23ee279b69683f29919` tested with this branch at `ddefe4263b`
- ✅ [eclair](https://github.com/pinheadmz/eclair/pull/4) master at `2dda79468a8b69a2acf7962cdac63245f7cc3ee8` tested with this branch at `ddefe4263b`
- ✅ [corepc](https://github.com/pinheadmz/corepc/pull/4) master at `818e5f2929ea5113176150b2d9f7c0248992d99c` tested with this branch at `ddefe4263b`
- ✅ [bitcoinjs-lib](https://github.com/pinheadmz/bitcoinjs-lib/pull/4) master at `ab9fad5978bc1f4fb6542d1cde903d4427c3344e` tested with this branch at `ddefe4263b`
- ✅ [NodeJS `bitcoin-core`](https://github.com/pinheadmz/bitcoin-core/pull/2) master at `24f3d0be7ab73089542de42cc8e31903727dbdf8` tested with this branch at `ddefe4263b`
## Benchmarks
To get a general idea of server speed vs. master I ran the functional test suite on all three platforms, three trials each, from the first and last commit of this branch. The first commit represents master, but adds a few extra functional tests, so the overall suite is the same in the last commit.
[Full results](https://docs.google.com/spreadsheets/d/1X8JI3k_mjKm9qUYNCV14TezTUBGOFTqHW-mucZOYRn4/edit?usp=sharing)
Summary:
Tested at 37ff331f60
There appears to be a 1-2% slow down on Ubuntu and MacOS but a 5% speed up on Windows
|| Ubuntu - master | Ubuntu - branch | MacOS - master | Macos - branch | Windows - master | Windows - branch |
|-|-|-|-|-|-|-|
|AVERAGE| 253| 260| 187| 190| 521| 493|
|% diff to master| | 2.766798419| | 1.604278075| | -5.37428023 |
ACKs for top commit:
vasild:
ACK 61020b36c5
theStack:
re-ACK 61020b36c5
Tree-SHA512: d39f782b9e6c7d67fdba5638fe9a1018b83062668c8b2ab0aa3fe363801f3c36a0ae97b8da0ea0395195e03a2c248a5d1511e5fa27c438c9bd7fca5c83d1ae4c
Remove the `Mutex` from the `threadpool` and `dbwrapper_concurrent_reads`
pool startup helpers. Fuzz targets are entered sequentially within a
process and parallel fuzzing uses separate processes/forks, which each
have their own copy of the global thread pool. Therefore, a mutex to
prevent two in-process callers from racing to start the pool isn't needed.
Limit how many read queries each worker executes. This significantly
speeds up the test, as each worker runs >90% fewer (2000 to 128)
expensive LevelDB operations (like `IteratorSeek`) but still
ends up hitting the intended target code.
Revert the `num_entries` max from 3000 back to 5000, as that didn't
have much effect on input speed and restores a bit of lost coverage.
Creates logic to deprecate logging categories but still
"support" them so the software doesn't quit with unknown category
on startup. Deprecated categories are always false and attempts
to switch them are logged as warnings.
The original function was already naturally split into two chunks:
First, we parse and validate the users' RPC configuration for IPs and
ports. Next we bind libevent's http server to the appropriate
endpoints.
This commit splits these chunks into two separate functions, leaving
the argument parsing in the common space of the module and moving the
libevent-specific binding into the http_libevent namespace.
A future commit will implement http_bitcoin::HTTPBindAddresses to
bind the validate list of endpoints by the new HTTP server.
The original function is passed to libevent as a callback when HTTP
requests are received and processed. It wrapped the libevent request
object in a http_libevent::HTTPRequest and then handed that off to
bitcoin for basic checks and finally dispatch to worker threads.
In this commit we split the function after the
http_libevent::HTTPRequest is created, and pass that object to a new
function that maintains the logic of checking and dispatching.
This will be the merge point for http_libevent and http_bitcoin,
where HTTPRequest objects from either namespace have the same
downstream lifecycle.
This is a refactor to prepare for matching the API of HTTPRequest
definitions in both namespaces http_bitcoin and http_libevent. In
particular, to provide a consistent return type for GetRequestMethod()
in both classes.
See https://www.rfc-editor.org/rfc/rfc7230#section-6.3.2
> A server MAY process a sequence of pipelined requests in
parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
but it MUST send the corresponding responses in the same order that
the requests were received.
We choose NOT to process requests in parallel. They are executed in
the order recevied as well as responded to in the order received.
This prevents race conditions where old state may get sent in response
to requests that are very quick to process but were requested later on
in the queue.
Sockets-touching bits copied and adapted from `CConnman::SocketSendData()`
Testing this requires adding a new feature to the SocketTestingSetup,
returning the DynSock I/O pipes from the mock socket so the received
data can be checked.
Co-authored-by: Vasil Dimov <vd@FreeBSD.org>
`SocketHandlerConnected()` adapted from CConnman
Testing this requires adding a new feature to the SocketTestingSetup,
inserting a "request" payload into the mock client that connects
to us.
This commit also moves IOErrorIsPermanent() from sock.cpp to sock.h
so it can be called from the socket handler in httpserver.cpp
Co-authored-by: Vasil Dimov <vd@FreeBSD.org>
Socket handling methods are copied from CConnMan:
`CConnman::GenerateWaitSockets()`
`CConnman::SocketHandlerListening()`
`CConnman::ThreadSocketHandler()` and `CConnman::SocketHandler()` are combined into ThreadSocketHandler()`.
Co-authored-by: Vasil Dimov <vd@FreeBSD.org>
