Use of http_ForceField() with the url is now banned.

vrt_null_blob was moved into varnishd and thus is only available
when a vmod is dlopen'ed from varnishd.

Provide an own implementation and make sure it is exported.

There was an inherent race between the expiry thread and other file
deletions.

We solve this by making clear that expiry owns the reference. When
some user action requires deletion, expiry is set to "now" and the
file is removed from the index. We use the srvref as a marker
for index removal. After removal from the index, the file can
not be found any longer, so gaining an srvref is not possible.

When expiry is first to delete the file, the file is removed from
the index and the ref is lost.

tus_file_shutdown() deletes all files.

This could interfere with the exp thread if it expired a file at the
same time.

Solve this race by first stopping the exp thread, then deleting all files
and then running final checks that exp is actually cleaned up.

in tus_file_final_concat(), we needed to get an fcore reference while holding
the srv lock for lookup.

Thus the srv lock would be kept until the fcore could get locked.

To avoid this situation, we add the option to also gain refcounts under the
server mutex.

I need to consider making this a system wide setting

If, for some reason, an fcore lock could not get aquired, the
expiry thread would keep the server locked until that file was
available again.

Avoid this situation with a trivial trylock and retry.

Keeping a local varaible and the struct response member with a pointer to
the fcore was unnecessary complex and a possible cause for error.

Now that holding a pointer is conceptually equal to holding a lock,
we should really avoid the local variable.

Also fixes an (unlikely) leaked lock for TUS_FINAL and method != POST

- move lock and unlock to tus_file.c
- clear the fcore pointer argument when the lock is not acquired

If a GET arrived before a file was complete, we would miss to unlock
it due to the fcore pointer missing in the response struct.

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