instead of ingesting only full blocks, make an analysis of data, and infer where to split.

for better portability on Linux kernel

though I really wonder if this is a property worth maintaining.

short term simplification

for easier local testing

ideally, this workspace would be provided from the ZSTD_CCtx* state

for non 64-bit systems

let's fill the initial stats directly into target fingerprint

that samples 1 in 5 positions.

This variant is fast enough for lazy2 and btlazy2,
but it's less good in combination with post-splitter at higher levels (>= btopt).

reported by @terrelln

…loss

ensure data can never be expanded by more than 3 bytes per full block.

suggested by @terrelln

…in the loop.

suggested by @terrelln

following a discussion with @felixhandte

detected by @felixhandte

due to integration of `sample5` strategy, leading to better compression ratios on a range of levels

strict C90 compliance test

so that it can be stored using standard alignment requirement (sizeof(void*)).

Distance function still requires 64-bit signed multiplication though,
so it won't change the issue regarding the bug in ubsan for clang 32-bit on github ci.

this helps make the streaming behavior more consistent,
since it does no longer depend on having more data presented on the input.

suggested by @terrelln

issue reported by @terrelln

instead of just for blind split.

This is in anticipation of adversarial input,
that would intentionally target the sampling pattern of the split detector.

Note that, even without this protection, splitting can never expand beyond ZSTD_COMPRESSBOUND(),
because this upper limit uses a 1KB block size worst case scenario,
and splitting never creates blocks thath small.

The protection is more to ensure that data is not expanded by more than 3-bytes per 128 KB full block,
which is a much stricter limit.

first block is no longer splitted since adding the @Savings over-split protection