SOCKS5 username/password authentication (RFC 1929)

[bluet]

Goal

Add SOCKS5 username/password sub-negotiation (RFC 1929) to proxybroker.negotiators.Socks5Ngtr so the broker can find/check/use SOCKS5 proxies that require credentials.

Why this is in scope

A meaningful slice of real-world SOCKS5 proxies (paid lists, corporate gateways, residential rotation services) require username/password auth. Without RFC 1929 support, proxybroker silently rejects them at the greeting (the proxy advertises method 0x02 'username/password', the broker expects 0x00 'no-auth' and bails). This directly limits what the tool can find/check/serve — its core mission.

Scope

• Socks5Ngtr.__init__: accept optional username/password (or pass through via kwargs).
• Greeting: when credentials are configured, advertise both methods (0x00, 0x02) instead of just 0x00.
• If proxy selects method 0x02, perform the RFC 1929 sub-negotiation:
  • Send: \x01 + uname_len + uname + passwd_len + passwd
  • Read: 2-byte reply (\x01 + status; status 0x00 = OK, anything else = fail).
• Plumb credentials through Proxy so callers can specify per-proxy creds.
• Provider parsing: support user:pass@host:port form for SOCKS5 entries (URI-style).
• Tests: greeting with both methods, sub-neg success/failure paths, byte-level format.

Acceptance criteria

1. Proxy('host', 1080, username='u', password='p') succeeds against a SOCKS5 proxy that requires RFC 1929 auth.
2. Proxy('host', 1080) against the same proxy fails with a meaningful error (not a generic BadResponseError).
3. SOCKS5 negotiator without credentials still passes the existing no-auth tests (regression).
4. New wire-level tests: greeting bytes (\x05\x02\x00\x02 when creds present), sub-neg request/reply bytes.

Out of scope

• GSSAPI auth (method 0x01) — much rarer in proxy ecosystems, separate ticket if asked.
• HTTP CONNECT proxy auth — separate ticket (Basic/Digest/NTLM/Negotiate are different protocols).

Estimated effort

~2-3 hours including tests. ~50 lines of code.