This separates more cleanly the goal of each part. At the same
time the prefix path file can be kept in the sources rather than
being in /tmp that could be altered during a run.

limit_choices_to has no effect on ManyToManyField with a
through model.

The latest version has a new default set of middleware so update
the list to match it and to keep the current functionality as well
as improve security.

The request processor has been moved from django.core to
django.template.

StaticFilesNode was removed so refactored the code to still
return the same data as before.

pattern wasn't used and is not available anymore.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

render_to_response is deprecated in Django 2.0 and render has
been available since 1.3. It's shorter to write and avoids the
writing of context_instance=RequestContext(request) in each of
its call.

Fix backup restore

See merge request !236

This ensure that whatever the outcome of the tests, the prefix is
cleaned up. Currently these are piling up in the /var/tmp folder.

The natural key generate was using a tuple in a tuple (which is good)
however the get_by_natural_key method was expecting a flat tuple.

This allows Django to serialize the database content in the correct
order.

Database hash doesn't exists anymore and rather than generating
natural keys that trigger the creation of get_by_natural_key
methods with way too many parameters, use tuples in tuples. This
make the code clearer to read as well as easier to maintain if the
natural key of a related field changes.