... if it looks like we were handling chunked encoding.

fellow has (and needs to have) its own strategy for allocating growing
objects and is basically working around the fetch_chunksize coming
from varnish-cache by recording if subsequent allocation requests are
growing the object (for chunked encoding) or are converging onto a
maximum (for content-length).

Now this strategy had an undesired side effect, that the newly
introduced fbo_segmem pool is always allocating the chunk size, but
the disk segment allocation was using the size from varnish-cache,
which, for the example in the ticket, would lead to 1MB chunks being
allocated, but trimmed down to only 16kb - for each allocation.

We now explicitly test if varnish-cache is requesting fetch_chunksize
and, if so, allocate the chunk size.

This brings the disk segment allocation in line with the mempool.

On the other hand, for chunked encoding, we will still over-allocate
and trim when the actual object is smaller than the chunk size, but
this is by design.

Fixes #60