fix fuzz integer overflow in cram encoder.

[jkbonfield]

Input files with very long CIGAR strings and consensus generated embedded reference can lead to exceptionally long CRAM blocks which overflow the check for large size fluctuations (to trigger new compression metric assessments).

Reformulated the expression to avoid scaling up values.

Credit to OSS-Fuzz
Fixes oss-fuzz 68225

[daviesrob]

Strictly, I think this can still overflow due to the + 1000 on both sides. However, by expanding out the brackets and subtracting 1000 from both sides it's possible to get something that behaves itself:

Suggested change

	((b->uncomp_size + 1000)/4 > metrics->input_avg_sz+1000 ||
	b->uncomp_size + 1000 < (metrics->input_avg_sz+1000)/4) &&
	(b->uncomp_size/4 - 750 > metrics->input_avg_sz ||
	b->uncomp_size < metrics->input_avg_sz/4 - 750) &&

Note that this relies on both b->uncomp_size and metrics->input_avg_sz being signed values. As the next part also has this requirement I don't think it's a major problem, but we might want to bear it in mind if we ever wanted to change either to be unsigned (e.g. size_t).

[jkbonfield]

I've worked through the expansion and I agree with the same thing. It's a bit obscure, so I'll add a comment.

[daviesrob]

Rebased to pick up the recent test fixes...