server: accept P2P peers over WebTransport

[sputn1ck]

Change Description

Browsers cannot open Bitcoin's raw TCP peer-to-peer transport. This change adds
an optional WebTransport listener so browser clients can exchange the existing
Bitcoin P2P byte stream with btcd over HTTP/3 and QUIC.

Each accepted WebTransport session carries exactly one client-opened,
bidirectional stream. The listener exposes that stream as a net.Conn and
feeds it into btcd's existing peer server; it adds no Bitcoin framing or
protocol changes.

The new configuration is opt-in:

• --webtransportlisten binds a UDP listener.
• --webtransportcert and --webtransportkey configure its TLS certificate.
• --webtransportpath selects the exact HTTPS endpoint.
• Repeatable --webtransportorigin flags extend the same-origin browser
  policy with exact origins. The exact value * accepts any valid HTTP(S)
  browser origin.
• --notcplisten allows a WebTransport-only server. Without it, the regular
  TCP listener continues to operate.

The wildcard remains fail-closed for malformed, duplicate, opaque null, and
non-HTTP(S) origins. Partial patterns such as https://*.example.com remain
invalid. Allowing every HTTP(S) origin lets any website ask a visitor's browser
to connect to the node and consume peer slots and bandwidth, so it requires an
explicit --webtransportorigin='*'. Origin policy is not client
authentication; non-browser clients can omit the header.

The listener bounds pending QUIC connections and upgraded sessions, applies
request and first-stream deadlines, rejects additional streams, and closes the
HTTP/3 connection with its btcd peer. Defaults remain unchanged when no
WebTransport listener is configured.

The paired Neutrino change supplies the browser client and a complete
ChainService synchronization test:
lightninglabs/neutrino#381

The commits are ordered for review:

1. Add the listener, configuration, and server wiring.
2. Harden resource cleanup and browser behavior, then add the real-Chrome
   integration proof.
3. Add the explicit all-HTTP(S)-origins policy and exercise it from Chrome.
4. Resolve the WebTransport-specific errcheck findings found during the
   final branch lint pass.

Steps to Test

Run the native unit, race, vet, and branch-diff lint checks:

go test ./internal/webtransport
go test -race ./internal/webtransport
go test ./...
go vet ./...
golangci-lint run --new-from-rev=master

Run the stock-browser integration test:

go test -v -tags=rpctest ./integration \
  -run '^TestWebTransportBrowserWASMPeer$' -count=1

The browser test builds the real Go/WASM peer, serves it from a different
HTTP origin, starts a full native btcd simnet node with
--webtransportorigin=*, pins a short-lived P-256 certificate by SHA-256 hash,
and verifies version/sendaddrv2/verack plus ping/pong. btcd's RPC view must
report the same client as inbound on the WebTransport listener.

Pull Request Checklist

Testing

• Your PR passes all CI checks.
• Tests covering the positive and negative (error paths) are included.
• Bug fixes contain tests triggering the bug to prevent regressions. (Not
  applicable: this is a new opt-in transport.)

Code Style and Documentation

• The change is not insubstantial. Typo fixes are not accepted to fight bot spam.
• The change obeys the Code Documentation and Commenting guidelines, and lines wrap at 80.
• Commits follow the Ideal Git Commit Structure.
• Any new logging statements use an appropriate subsystem and logging level.

📝 Please see our Contribution Guidelines for further guidance.

[jjrauch32-lab]

Ok

[jjrauch32-lab]

Ok

[jjrauch32-lab]

Ok

[jjrauch32-lab]

Ok

[blessingblockchain]

hi @sputn1ck @Jason-123-cyber i am a security researcher,

I identified critical issues in your code that would lead to fund loss. I want to ask: is your bug bounty still active, and are there rewards for valid vulnerabilities?

Your response is most appreciated