BUG/MAJOR: lb-chash: fix key calculation when using default hash-key id

BUG/MAJOR: lb-chash: fix key calculation when using default hash-key id

A subtle regression was introduced in 3.0 by commit faa8c3e02 ("MEDIUM:
lb-chash: Deterministic node hashes based on server address"). When keys
are calculated from the server's ID (which is the default), due to the
reorganisation of the code, the key ended up being hashed twice instead
of being multiplied by the scaling range.

While most users will never notice it, it is blocking some large cache
users from upgrading from 2.8 to 3.0 or 3.2 because the keys are
redistributed.

After a check with users on the mailing list [1] it was estimated that
keep the current situation is the worst choice because those who have
not yet upgraded will face the problem while by fixing it, those who
already have and for whom it happened smoothly will handle it just
right again.

As such this fix must be backported to 3.0 without waiting (in order
to preserve those who upgrade from two redistributions). Please note
that only configurations featuring "hash-type consistent" and not
having "hash-key" present with a value other than "id" are affected,
others are not (e.g. "hash-key addr" is unaffected).

[1] https://www.mail-archive.com/haproxy@formilux.org/msg46115.html

(cherry picked from commit 03e9a5a1e74b88c7ab7a9522c0345f8d54ec373b)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit cb65f85d54ef5dbb0222e1d66ff49476d728c113)
[wt: dropped the non-existing vtc]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 3e498531d114fe65ba4c907cd1045366ef1a7bae)
Signed-off-by: Willy Tarreau <w@1wt.eu>