Previously, a 32-bit overflow could happen while validating atom entries
count.  This allowed processing of an invalid atom with entrires beyond
its boundaries with reads and writes outside of the allocated mp4 buffer.

Reported by Prabhav Srinath (sprabhav7).

Previously, data validation checks did not cover the cases when the output
contained empty buffers.  Such buffers are considered illegal and produce
"zero size buf in output" alerts.  The change rejects the mp4 files which
produce such alerts.

Also, the change fixes possible buffer overread and overwrite that could
happen while processing empty stco and co64 atoms, as reported by
Pavel Kohout (Aisle Research) and Tim Becker.

Per ISO 14496-12 Section 8.6.2, sync sample numbers must be 1-based.
A zero-valued stss entry caused ngx_http_mp4_seek_key_frame() to
return a key_prefix exceeding the samples consumed in the forward
stts pass, which led the backward loop in ngx_http_mp4_crop_stts_data()
to walk past the beginning of the stts data buffer.

The fix validates each stss entry in ngx_http_mp4_seek_key_frame()
and returns an error if a zero sync sample is encountered.  The
function signature is changed to return ngx_int_t so it can signal
errors to the caller.

When cropping stsc atom, it's assumed that chunk index is never 0.
Based on this assumption, start_chunk and end_chunk are calculated
by subtracting 1 from it.  If chunk index is zero, start_chunk or
end_chunk may underflow, which will later trigger
"start/end time is out mp4 stco chunks" error.  The change adds an
explicit check for zero chunk index to avoid underflow and report
a proper error.

Zero chunk index is explicitly banned in ISO/IEC 14496-12, 8.7.4
Sample To Chunk Box.  It's also implicitly banned in QuickTime File
Format specification.  Description of chunk offset table references
"Chunk 1" as the first table element.

Currently an error is triggered if any of the chunk runs in stsc are
unordered.  This however does not include the final chunk run, which
ends with trak->chunks + 1.  The previous chunk index can be larger
leading to a 32-bit overflow.  This could allow to skip the validity
check "if (start_sample > n)".  This could later lead to a large
trak->start_chunk/trak->end_chunk, which would be caught later in
ngx_http_mp4_update_stco_atom() or ngx_http_mp4_update_co64_atom().

While there are no implications of the validity check being avoided,
the change still adds a check to ensure the final chunk run is ordered,
to produce a meaningful error and avoid a potential integer overflow.

A specially crafted mp4 file with an empty run of chunks in the stsc atom
and a large value for samples per chunk for that run, combined with a
specially crafted request, allowed to store that large value in prev_samples
and later in trak->end_chunk_samples while in ngx_http_mp4_crop_stsc_data().
Later in ngx_http_mp4_update_stsz_atom() this could result in buffer
overread while calculating trak->end_chunk_samples_size.

Now the value of samples per chunk specified for an empty run is ignored.

Unordered chunks could result in trak->end_chunk smaller than trak->start_chunk
in ngx_http_mp4_crop_stsc_data().  Later in ngx_http_mp4_update_stco_atom()
this caused buffer overread while trying to calculate trak->end_offset.

While cropping an stsc atom in ngx_http_mp4_crop_stsc_data(), a 32-bit integer
overflow could happen, which could result in incorrect seeking and a very large
value stored in "samples".  This resulted in a large invalid value of
trak->end_chunk_samples.  This value is further used to calculate the value of
trak->end_chunk_samples_size in ngx_http_mp4_update_stsz_atom().  While doing
this, a large invalid value of trak->end_chunk_samples could result in reading
memory before stsz atom start.  This could potentially result in a segfault.

Since 4611:2b6cb7528409 responses from the gzip static, flv, and mp4 modules
can be used with subrequests, though empty files were not properly handled.
Empty gzipped, flv, and mp4 files thus resulted in "zero size buf in output"
alerts.  While valid corresponding files are not expected to be empty, such
files shouldn't result in alerts.

Fix is to set b->sync on such empty subrequest responses, similarly to what
ngx_http_send_special() does.

Additionally, the static module, the ngx_http_send_response() function, and
file cache are modified to do the same instead of not sending the response
body at all in such cases, since not sending the response body at all is
believed to be at least questionable, and might break various filters
which do not expect such behaviour.

Most atoms should not appear more than once in a container.  Previously,
this was not enforced by the module, which could result in worker process
crash, memory corruption and disclosure.