feat: support hashed_password users (mysql_native_password)

[takaidohigasi]

Summary

Adds a hashed_password alternative to password for proxy.users entries, so personal accounts whose plaintext the interceptor never sees can authenticate against the inbound handshake. The plaintext is no longer required for proxy-side auth.

proxy:
  users:
    - username: "app_user"
      password: "app_pw"
    # NEW — alternative to password:
    - username: "personal_alice"
      hashed_password: "*4DF1D66463C18D44E3B001A8FB1BBFBEA13E27FC"

The hashed form is MySQL's standard mysql_native_password stored value (* + 40 hex chars = * + SHA1(SHA1(plaintext)) hex-encoded), i.e. exactly what mysql.user.authentication_string carries for that plugin.

How

• go.mod adds a replace directive pointing at github.com/takaidohigasi/go-mysql@0d8f39fd, which is the head of go-mysql-org/go-mysql#1129. The fork only touches server/ files (Credential, InMemoryAuthenticationHandler.AddUserWithHashedPassword, HashedPassword value type with shape validation); the client path the interceptor uses for backend connections is unaffected. Drop the replace once upstream merges + tags a release.
• internal/config/config.go — new UserConfig.HashedPassword field. Validator enforces "exactly one of password / hashed_password" per entry and shape-checks the hashed form at load time so typos surface immediately instead of as login errors hours later.
• internal/proxy/server.go — register hashed users via the fork's AddUserWithHashedPassword; mysql.DecodePasswordHex decodes the *XXXX... form to the underlying 20 bytes. Hashed users intentionally do not appear in userPasswords, so the existing missing-entry lookup in handleConnection surfaces them with a sharpened error message at backend-connect time.

Scope deliberately limited

Path	Status
Inbound handshake (client → proxy)	✅ Supported via this PR.
Outbound backend connect (proxy → backend)	❌ Still requires plaintext. Hashed-only users authenticate successfully but the session terminates at backend-connect with a clear error rather than running queries.

End-to-end query forwarding for hashed-only users would need either (a) go-mysql client-side hash-based auth (so we can reuse the hash for the outbound connect), or (b) a per-user backend_password override field. Both are tracked as follow-ups; this PR unblocks audit-only use cases — personal users no longer break config validation, and their auth attempts now appear in audit logs instead of silently being rejected.

Test plan

• TestLoad_HashedPassword_Accepts — shape-correct value round-trips through Load.
• TestLoad_HashedPassword_RejectsBoth — both fields set fails fast.
• TestLoad_HashedPassword_RejectsMalformed — 4 typo categories (missing leading *, too short, too long, non-hex).
• TestUsersWiring "hashed-password users skip userPasswords" — registers on the auth handler but stays absent from userPasswords (load-bearing for the clear-error path).
• gofmt -l . clean
• go vet ./... clean
• go build ./...
• go test -race -count=1 ./... (full suite incl. integration)

Follow-up to remove the replace directive

Once go-mysql-org/go-mysql#1129 merges and a tagged release ships, switch go.mod back to the upstream module + new tag and remove the replace line. The new exported API (HashedPassword, AddUserWithHashedPassword, Credential.HashedPasswords) is the same in upstream so no source changes here are needed.

🤖 Generated with Claude Code