to be ignored in VSCAPI and do so there.

t_prev from the request we are cleaning up is not the most recent
relevant time stamp, in particular for H2

Since the last_lru tracks epoch time, it needs the double precision
floating point type to accurately track the time.

Fixes: #2527

Ref: c15eefb1

This is already possible with some overhead (for example with a
de-tour via vcl_pass), but I see absolutely no reason why we should
not allow direct restarts from recv.

The use case is to rewrite the request and re-start processing of the
rewritten request as if it was received as such. This is also possible
already with some vcl sub juggling, but is complicated by the VCL call
loop detection. Use of restarts avoids this complication and is safe
due to max_restarts.

just a minor stylistic cleanup: Early returns should mark exceptional
cases.

how many instances of the VSC set there are.

generalize functions and methods, some additional cleanup

This eliminates a O(N) lookup when we want to do something
(ie: Destroy) to a VSC segment subsequently.

...Now that we will need more than one integer.

This ensures we don't end up with a VSL batched record with conflicting
ids, which breaks the -g grouping modes.

Originally it was the plan that the JSON would be gzip'ed in the
VSM, but to avoid exposing VGZ in the API we didn't, but kept the
gzip'ed JSON in the generated VSC code because why not?

Well now we know why not:  It wastes a lot of time for very little space,
in particular if you have many backends.

Provides some relief for: #2513 & #2518

phk probably has this in a global flexelint config