fix: make SNMPv3 keys valid by construction

[ilyam8]

Summary

Fifth step of the bug-fix phase: an SNMPv3 key is valid for its protocol by construction.

The USM took keys and salts of any length:

• HMAC-MD5-96 and HMAC-SHA-96 cut a key longer than the 64-octet block (RFC 2104 hashes it); crypto/hmac panicked
  for an HMAC-SHA-2 key under 14 octets in FIPS 140-only mode.
• DES indexed past a key shorter than 16 octets or a salt shorter than 8, and panicked, on decode and encode.
• AES took any key aes.NewCipher takes, so an AES-128 key of 32 octets encrypted with AES-256, and any salt (9 and
  16 octets were accepted inbound). AES-CFB panicked in FIPS 140-only mode.
• Localizing an empty passphrase dropped the error and returned an empty key. A new engine ID gave a user configured
  with keys and no passphrases the empty keys, so a trap signed with the empty key, which anyone can compute, passed,
  and so did an unauthenticated trap from any engine ID for keys-only DES and no-privacy users.
• Per-site checks stood in for the missing rule: guards in the engine and in the answer check refused an empty key;
  SnmpEncodePacket signed with one; the signer recovered a panic onto stdout and returned no message and no error.

Now:

• One rule in the internal/usm specs every path reaches: an authentication key is exactly the size of its hash, a
  privacy key exactly its cipher's key (AES's, or DES's 16 octets of key and pre-IV, RFC 3414 section 8.1.1.1), a salt
  exactly 8 octets (RFC 3414 section 8.3.2, RFC 3826 section 3.3.2). Digest, Verify, Encrypt and Decrypt
  refuse anything else, and AES-CFB in FIPS 140-only mode, with an error.
• Localizing an empty passphrase is an error. InitSecurityKeys derives the missing keys from non-empty passphrases
  and checks every key with the rule, so a table's Add refuses a key that does not fit.
• A key in the parameters is localized to AuthoritativeEngineID (RFC 3414 section 2.6): a new engine ID re-derives
  the keys from the passphrases (traps from new engines keep working), and parameters with a key given without its
  passphrase cannot take another engine ID. Such a user decodes no message naming another engine ID, whatever its
  security level, security model or user name, and such a client takes no engine ID from discovery.
• The signer's recover, the engine's empty-key guard and the answer check's empty-key test go: the rule catches what
  they caught, with an error.

Behavior changes:

Case	Before	After
Authentication key not of the hash size	used (cut or zero-padded)	error
AES key of another size than the protocol's	used (another AES size)	error
DES key shorter than 16 octets, or salt shorter than 8	panic	error
Salt longer than 8 octets	accepted	error
AES-CFB in FIPS 140-only mode	panic	error
Empty passphrase	empty key	error, no key
Trap signed with the empty key, user with keys only	accepted	rejected
Unauthenticated trap from another engine ID, user with keys only	accepted (DES, no privacy, long-hash Blumenthal); rejected by a failed key derivation (other privacy protocols)	rejected
Client with keys only and no engine ID	DES, no privacy: discovery adopts the agent's, signing fails for want of a key; other privacy protocols: discovery fails (a failed key derivation)	discovery fails, the client's security parameters unchanged
Client with keys only, reply naming another engine ID (also a forged Report)	DES, no privacy: ErrUnknownEngineID; other privacy protocols: undecodable (a failed key derivation)	undecodable: sent again, then the binding error
Signing panic	message dropped, stack on stdout	cannot happen; key errors returned
DES key derived for an HMAC-SHA-family user	the 20+-octet localized key	its first 16 octets (same ciphertext)

Passphrases stay accepted at any non-empty length (RFC 3414 section 11.2 asks for 8 octets; Netdata's jobs may use
shorter ones). Netdata uses passphrases only; its trap receiver's error labels keep working ("authentication",
"decrypting").

Tests

• First commits: pins of the key and salt lengths the USM took beyond its protocols'.
• Golden flips: the codec's 80-octet keys and DES decode panic; the USM key golden (DES keys of 16 octets, empty
  passphrases); the USM decrypt golden (DES panics and wrong salts become errors); the engine goldens (the rule's
  errors replace the guard's, AES-CFB errors replace recovered panics).
• Rule tests: TestDigest (keys of 0 to 100 octets), TestPrivKeyAndSaltLengths, TestUSMKeyLengths,
  TestUSMEmptyPassphraseKeys, TestSnmpEncodePacketEmptyKey, TestUSMFIPS140OnlyShortSHA2Key, the hand-forged
  empty-key trap of TestUSMTrapUnauthenticated; the RFC 3414 key vectors still match.
• Engine binding: TestUSMKeysBoundToEngine (every protocol pair; the trap table, a single trap user with its own or
  the message's flags, and SnmpDecodePacket; unauthenticated, security model 2 and empty-identity messages from
  another engine rejected, signed ones from the keys' engine accepted), TestUSMAdoptEngineID (the rule per parameter
  shape), engine scenarios for a keys-only client with another configured engine ID and a forged Report from another
  engine.

Validation

• Local: golangci-lint, race tests, FIPS 140-only, six cross-builds, govulncheck and netsnmp playback pass.
  GOARCH=386 and the end-to-end suite run in CI.
• Benchmarks: allocations and bytes of USM encode and decode and of an SNMPv3 Get are unchanged; time within about 3%.
• 36 mutants of the changed code: all killed but one equivalent.
• Two independent reviews (security of the key invariant; tests and docs): no forgery, key or salt slipped past the
  rule on any path, FIPS 140-only included. Their findings are in the last commit: every cipher error wrapped at one
  point (DES refused in FIPS 140-only mode now reads like AES-CFB's refusal), one privacy-key check, tests of the
  error words Netdata's trap receiver labels, and two doc corrections.
• An external final review found that dropping a key given without a passphrase let messages that use no key through
  (unauthenticated traps from other engines to keys-only users). The last commit binds such parameters to their engine
  ID instead; the review's own probes pass.