If we can only save part of the request body locally, there is no need to discard
all of it.

Yet, if checksums are enabled, we will still fail later with a 413.

If we set a done url (which is sent in Content-Location or Location for
a 301) with an empty file (POST with Upload-Length: 0), we would trigger
the two removed assertions. They are bad because a zero sized upload
is legit and can have a Content-Location.

... at compile time

It can still fail later, though.

Ref:
https://github.com/varnishcache/varnish-cache/commit/681c11998ec56dc4460a30585210f95a7850ea3b

Ref varnish-cache ed13c9f24e60627b356d27f23f6548e4a44515df

It might work with earlier versions, but I have not tested that yet.

to avoid conflicts with the original files when -I includes the original
sources.

see https://httpwg.org/specs/rfc7231.html#header.content-location

- use the new dedicated field to store the location such that we can
  still properly send metadata with responses to HEAD requests

- always send the location, not just for GET 301s

- no need to generate a 410 as long as we still have the metadata

- retire TUS_REDIRECT type, we do not need it (files with a redirect
  remain intact).

This implies a file version change.

Later in the project, we would want to upgrade existing files, but for
now, I assume the number of users be so close to zero that we can put
the burdon on them to lose their existing uploads once during upgrade.