… in the system tmp folder

which never get cleaned up, and have it return a data stream of the zip file contents intead.

Next up: fix the two places in the rest of the code which were calling this, and adapt them to
use the data stream in lieu of the file name.

the first caller of create_attachments_zipfile(), to treat the result
as a data stream, and catch and record any IOErrors as failed Export
objects in the database.

The prior logic was disgusting: it created a zip file in /tmp, read it
into memory to create a new file (a copy) elsewhere in the filesystem,
and never bothered with the original file in /tmp.

…(), to

accept the result back as a stream, and used django's FileWrapper to respond
to the http request immediately, rather than calling another to go read the
temp file first (which, of course, never gets cleaned up).

The response_with_mimetype_and_name() function in utils.export_tools.py is just
a mess: it depends on reading all its responses from the file system, and
mimetype assumption that all valid response types start with 'application/' is
just flat wrong!

… disposition

string, which should include the filename (xform id string).

…ary file-like

object corresponding to the zipped file, rather than the entire data stream of the
file contents, since it is safer for the functions which invoke it to handle it
themselves.

As with the previous revision, this function does *not* leave files in /tmp after
the request is completed.

…le, rather than

the full data stream of the prior version.

… handle of the zip file,

rather than the full data stream of the prior version.