peer: bound peer-controlled resource growth

[yyforyongyu]

Change Description

Bound the resources a peer can consume through inbound pings and queued
outgoing messages.

Inbound ping handling now has two limits:

• Pong replies are limited to one per second with a burst of 20. Pings above
  that reply budget are accepted without a Pong.
• Peers exceeding ten pings per second with a burst of 200 are disconnected.
  This flood check also covers pings whose requested Pong size would otherwise
  be ignored.

The per-peer outgoing backlog is also capped at 10,000 messages and 16 MiB of
charged memory. Queue accounting covers fixed overhead and the high-risk
dynamic payloads without serializing messages on the hot path. An overflowing
peer is disconnected while the queue remains serviced until teardown, avoiding
deadlocks with synchronous senders.

Release notes are included for 0.21.3 and 0.20.4.

Open Question

The reply budget deliberately deviates from BOLT 1's requirement to answer
valid pings. A peer using those pings for liveness may close the connection when
its Pong is skipped, so the 1-10 ping/second band can relocate the disconnect
decision to the remote peer and make lnd appear unresponsive. Should the two
tiers remain, or should they be collapsed into the flood disconnect threshold?
This draft implements both tiers so reviewers can evaluate the concrete
behavior.

Steps to Test

GOWORK=off go build ./peer/... ./lnwire/...
GOWORK=off go test ./peer/
GOWORK=off go test -race ./peer/
GOWORK=off go vet ./peer/
GOGC=50 make lint

The queue-accounting and teardown-drain regression tests were also mutation
tested by removing their respective implementation lines and confirming each
test failed.

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.

Code Style and Documentation

• The change is not insubstantial.
• The change obeys the documentation and 80-column guidelines.
• Commits follow the ideal Git commit structure.
• New logging statements use appropriate levels.
• No lncli commands are added.
• Release-note entries are included.

[github-actions]

🔴 PR Severity: CRITICAL

file classification | 4 files | 500 lines changed

🔴 Critical (1 file)

• peer/brontide.go - modifies peer connection resource-limiting logic (ping/pong flood protection, outgoing message queue caps) in the brontide encrypted-transport layer

🟢 Low (3 files)

• peer/brontide_test.go - test-only change
• docs/release-notes/release-notes-0.20.4.md - release notes
• docs/release-notes/release-notes-0.21.3.md - release notes

Analysis

The substantive change is entirely in peer/brontide.go, which falls under the peer/*/brontide/* critical category (encrypted peer connections). It adds new resource-bounding logic for inbound pings (rate limiting, flood-based disconnects) and the outgoing message queue (size/memory caps with disconnect-on-overflow), directly affecting peer connection liveness and DoS resistance. No bump conditions apply (only 2 non-test files changed, ~194 non-test lines changed, single critical package touched). This is exactly the kind of peer-protocol change that warrants expert review, and the PR author itself flags an open design question about ping/pong disconnect semantics deviating from BOLT 1.

---

_{To override, add a severity-override-{critical,high,medium,low} label.}