This can be used to monitor the queue size in bytes rather than number of files

This can now be safely use to avoid overloading the queue.

This is to allow the user to set the merging options to avoid
recompression of input data into the output file when the
compression algorithm or level are different.

ROOT-9779 #resolve

In core/zip/inc/Compression.h was introduced RCompressionSetting class with set of enumerated classes for compression level, compression algorithm and default compression settings

The callback mechanism as implemented is not what is needed by CMS,
as previously thought. In order to allow the final goal of avoiding
oversubscription of the machines on which the TBufferMerger is used
within a framework, this functionality is better removed in order to
allow doing away also with the separate output thread currently needed
by TBufferMerger.

This makes it again as it was previously implemented by Vassil
in commit 92f1f502. Suggested by Enrico as easier to read.

This reverts commit ff557b31 while we
work on a fix for when IMT is disabled.

The initialization of TFileMerger with {false, false} means that
it will not create local copies of the TMemFiles it receives, and
that histograms will be merged as they appear, and not accumulated
until the end. To keep things consistent, other initializations
were moved into the same place.

This will allow breaking up the WriteOutputFile() function into smaller
functions, one for collecting buffers currently enqueued for merging,
and another for the actual merging. The first will be called by the
worker thread upon pushing into the queue, while the second will be
converted to run into a separate task, rather than a thread.

TBufferMerger is not meant to be streamed or saved to disk.

This avoids creating an unnecessary std::unique_ptr<TFile> just to
be able to call Init() with it.

We should only bump the ClassDef version when we change persistent data mamber.

This patch allows TFileMerger to work with externally created TFile-s. Being
able to control the creation of the TFile objects give us a chance to use
in-memory files. This is very helpful in benchmarking when we want to simulate
fast disks or we just want to avoid disk wearout.

This function lets users decide how much data should be accumulated
in buffers before being merged into the output file with TFileMerger.

Add methods TBufferMerger::GetQueueSize() and
TBufferMerger::RegisterCallback() to alow user
to control the rate at which data is pushed into
the merging queue. In our test, we use the callback
function to launch tasks asynchronously whenever a
buffer is done processing.

In rare occasions, the main thread (running ~TBufferMerger())
may inject the nullptr after the writing thread has checked in the
while loop if fQueue is empty, but before it puts itself in
the wait queue, which causes a deadlock with the writing thread
waiting for data, and the main thread waiting to join it. This
commit avoids the deadlock by using only a single mutex for all
operations on the queue.

Leaving management of objects in the TBufferMergerFiles and related
TMemFiles created from the TBufferFiles from the queue in TBufferMerger
leads to race conditions that may cause a crash due to double delete
of objects within the TMemFiles. This problem can be largely avoided,
although not completely avoided, if the management of the destruction
of these objects is done by hand by in user code. With these
modifications, the tests now run tens of thousands of times without
failure, compared with just a bit over a hundred times until a failure
before.

The usage of the TBufferMerger implied several changes of directory.
With the usage of TDirectory::TContext the state of ROOT is not changed.
Following the statement above, a change in behaviour is introduced. When
a user gets a file from the TBufferMerger with the GetFile method, it is
her responsibility to "cd" into it not to introduce an implicit change
of directory. This is clearly documented in Doxygen.

TBufferMerger is a class to facilitate writing data in
parallel from multiple threads, while writing to a single
output file. Its purpose is similar to TParallelMergingFile,
but instead of using processes that connect to a network
socket, TBufferMerger uses threads that each write to a
TBufferMergerFile, which in turn push data into a queue
managed by the TBufferMerger.

These classes were originally written by Witold Pokorski and
Philippe Canal for the GeantV project. There, they are named
TThreadedMergingServer and TThreadedMergingFile, respectively.
The imported code was then modified into the current version to
be used initially by TDataFrame classes, and later by general
ROOT users.