Reduce timing leakage from hash_digest_two_compression_rounds

[danielsn]

Currently, s2n balances the number of hash rounds by forcing a second hash compression when needed. This is done by hashing one extra block's worth of bytes. This causes extra btyes to be copied, creating a small timing inefficiency. Explore reducing this.

[alexw91]

#664 has added a test that enforces an upper bound of 68 LLVM time units (roughly equivalent to CPU cycles) for HMAC timing differences on every build of s2n. This is ~20 nanoseconds on a 3.3 GHz CPU, and well below the microsecond level timing leaks required for the original Lucky13 and Lucky Microsecond attacks.

This issue is tracking reducing that 68 CPU cycle upper bound.

[boquan-fang]

We should investigate this to determine if this is still an issue.