kick the expiry thread

this would lead to DELETEs being always responded to with a 404

This does not make a difference for HTTP1, and as we only use HTTP1
backends, does not many any difference right now.

Uploading files larger than 4GB could lead to an infinite loop and
client requests failing with 423 Locked forever.

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.