persist log level to reinitialize logger for eos tus

[butonic]

makes log lines for actual eos / xrdcopy cmds reappear ;-)

[labkode]

This approach looks wrong. The logger should be already present in the context given to the function

[butonic]

The tus hander disconnects the internal handling of the storage write by creating a new context. The goal is to let the server write as many bytes as possible. I raised this as an issue upstream. So it is by design.

That being said I think it helps debugging because admins can lookup the id and if needed increase the loglevel for a specific upload. We could even add a service or an api to the dataprovider that can manage ongoing uploads.

[labkode]

@butonic please create an issue to remember about that upstream fix for later cleanup.
Why this fix is not needed for the localfs?

I've started refactoring the tus handler and basically the way data uploads/downloads are working here: #828

[butonic]

we should pass a logger / context down when initializing the service