The default initial position for synthesizing zero hashes should be changed

[jifyang]

In delivery service steering, the response isn't correct if config two or more targets whose types are STEERING_ORDER and values are negative.

Root cause analysis:

In function synthesizeZeroHashes(), if hashableMap is empty, the initial position for putting the zero hashable with negative order value will be 0 (the variable minHash).

In the following process, 0 will be selected as the hash value for the first zero hashable, then the negative values -1, -2, ... in type long will be tried to generate the hash value in type double for the other zero hashables. There are three issues:

1. The NaN will be generated as the hash value next to the hash value 0. This will cause wrong result.

2. There are a large number of negative values -1, -2, ... in type long will be mapped to NaN in type double. This will consume much computation and cause slow response.

3. The negative values in type long and type double aren't correct in this scenario. For the negative values, the value in double type is ascending when the value in type long is descending (ref the function getSafeHash).

[mitchell852]

@rawlinp - is this a problem? should we just prevent negative order values instead?

[rawlinp]

I don't think we should prevent negative order values. I'm not exactly sure what the problem is, since "the response isn't correct" doesn't tell me how the response is actually incorrect. @jifyang can you clarify how the response is incorrect? Is the ordering unexpected? Can you show your steering config and TR responses?

[rawlinp]

I would add, anything that changes the way TR consistent hashes is extremely risky and could lead to TR sending clients to cold caches, causing a lot of disruption to the CDN. So I would need to know that the changes to the consistent hashing functions do not actually change how TR would consistent hash requests.