BUG/MINOR: jwt: don't truncate binary HMAC secrets at the first NULL byte

BUG/MINOR: jwt: don't truncate binary HMAC secrets at the first NULL byte

When jwt_verify() is used with an HMAC algorithm and its secret is passed
via a variable, the secret is truncated at its first NUL byte. RFC 7518
recommends random HMAC keys at least as long as the hash, which are
commonly distributed base64-encoded and fed to haproxy through something
such as "str(<b64>),b64dec" into a variable. About one random 32-byte key
out of eight contains a NUL byte. With such a key, all legitimately signed
tokens are rejected (traffic impact for the site), and tokens signed with
only the bytes located before the first NUL are accepted instead, which
for a NUL in the first bytes of the key means that a client can forge
valid tokens after a trivial brute force. Configurations passing the
secret as a string constant are not affected since the config parser
cannot produce a NUL byte there.

This can be reproduced with this config:

    http-request set-var(txn.key) str(YQBiY2RlZg==),b64dec   # "a\0bcdef"
    http-request return status 200 hdr x-res "%[req.hdr(x-tok),jwt_verify(HS256,txn.key)]"

A token signed with "a\0bcdef" returns 0 and one signed with "a" returns 1.

This fix should be backported to all supported versions.