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

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