...when we are using global entry numbers and therefore each
thread-local TChain has already been constructed with all files.

Previously all the dataset information was stored in the thread-local
TTreeViews, causing data duplication between threads and requiring
that TTreeProcessorMT queries it when it needs part of it.
Now TTreeProcessorMT stores all the dataset information (tree name,
filenames, friend names, friend file names, entry list) as constant
thread-global data which is passed down to TTreeView::GetTreeReader.

Fixes ROOT-9452

This reverts commit 5298b418.

This commit was mistakenly committed. PR was opened in #1730, but it was
closed and moved to #1761. I didn't notice this and created another PR
in #1980.

This change was causing 100+ failures in runtime cxxmodules nightlies.
(Eg. https://epsft-jenkins.cern.ch/job/root-pullrequests-build/29183/testReport/junit/projectroot/runtutorials/tutorial_fit_FittingDemo/)
We want to have **proper** PrebuildModulesPaths which information were
extracted from LD_LIBRARY_PATH and DYLD_LIBRARY_PATH, not a random ".".

Because of this commit, we were trying to autoload libraries generated
by roottest on-demand (for example "./h1analysisTreeReader_C.so") This
is not an intentional behavior, these autogenerated libraries are
already loaded by roottest and what we want to do is to load **proper**
libraries like libHist.so instead.

The current failure in snapshot is due to an ABI incompatibility (or so it seems) that we may have encountered before.
The failing line is:
{code:c++}
auto snapshotRDF = std::make_shared<RInterface<RLoopManager>>(std::make_shared<RLoopManager>(nullptr, validCols));
{code}
and one of the component of make_shared is the call to the following shared_ptr constructor
{code:c++}
      // This constructor is non-standard, it is used by allocate_shared.
      template<typename _Alloc, typename... _Args>
        shared_ptr(_Sp_make_shared_tag __tag, const _Alloc& __a,
                   _Args&&... __args)
        : __shared_ptr<_Tp>(__tag, __a, std::forward<_Args>(__args)...)
        { }
{code}
Note the use of std::forward.

The snapshot test has 2 steps:

1. Do the work, including a call to SnapshotImpl which contains the problem line, with only compiled code
2. Do the same work relying on interpreted code, in which case SnapshotImpl is called via the interpreter.

The symptoms of the failure is that **if** the snapshot test is compiled with optimization then

a. The compiled version works fine
b. In the interpreted version the constructor of the RInterface is wrong because the shared_ptr its constructor sees is **not** initialized.

 If the snapshot test is compiled without optimization then both steps succeeds.  The main difference between the two is the amount of fully realized (i.e. non-inlined) functions emitted by the compiler.

In the success fully case we have a stack like

{code}
interp SnapshotImpl calls
  compiled std::make_shared<ROOT::Detail::RDF::RLoopManager …  [in debug mode. this routine and down are used compiled]
    compiled  std::allocate_shared<ROOT::Detail::RDF::RLoopManager
      ... implementation details .. all compiled.
        compiled ROOT::Detail::RDF::RLoopManager::RLoopManager
  compiled  std::make_shared<ROOT::RDF::RInterface …
    compiled  std::allocate_shared<ROOT::RDF::RInterface …
      compiled  std::shared_ptr< ROOT::RDF::RInterface
        compiled std::__shared_ptr<ROOT::RDF::RInterface<ROOT::Detail::RDF::RLoopManager
{code}

{code}
interp SnapshotImpl calls
  interp std::make_shared<ROOT::Detail::RDF::RLoopManager …
    interp  std::allocate_shared<ROOT::Detail::RDF::RLoopManager
      ... implementation details .. all interpreted.
        compiled ROOT::Detail::RDF::RLoopManager::RLoopManager
  interp  std::make_shared<ROOT::RDF::RInterface …
    interp  std::allocate_shared<ROOT::RDF::RInterface …
      interp  std::shared_ptr< ROOT::RDF::RInterface
        compiled  std::__shared_ptr<ROOT::RDF::RInterface<ROOT::Detail::RDF::RLoopManager
{code}

I.e. the major difference is that we have the shared_ptr constructor (which contains std::forward) being interpreted  (rather than compiled) and calling a compiled function (the base class constructor) that takes (is given) an std::forward.   It seems that the parameter and then mangled/placed-wrong in that case.

If I recall correctly this is a know ABI incompatibility between clang and gcc; especially (only?) if it involves temporary.

Splitting the line in two statement, works around the problem:
{code:c++}
      auto rlm_ptr = std::make_shared<RLoopManager>(nullptr, validCols);
      auto snapshotRDF = std::make_shared<RInterface<RLoopManager>>(rlm_ptr);
{code}

In my case, it solves the problem because more of the '2nd' make_shared called are inlined by the compiler (when generating code for the 1st step), including the __shared_ptr constructor ... forcing the interpreter to generate the code and hence side-stepping the issue.  [And if the std::forward issue is limited to temporary it would side-step the issue even if the  __shared_ptr constructor was still outline.

...i.e. when no friends and no TEntryList are present, so that we can
use local rather than global entry numbers. If this is the case,
now TTreeProcessorMT spawns one task per input file which reads the
TTree cluster boundaries and spawns one sub-task per cluster.

This should decrease the amount of file switches that each thread-local
TChain performs during an event loop, as each thread will tend to
process clusters that belong to the same file.

This is necessary to give the user a clear error message,
since otherwise the build will go on and fail anyway with
a cryptic message. See ROOT-9441.

Modernise the macro as suggested here https://root-forum.cern.ch/t/root-tutorial-chapter-5-3-modifications/29266

Thanks Philippe!

Introduced by commit fc5d4ce6.

There is also no longer the need to add BUILTINS OPENSSL
to targets linking with the builtin version.

To link against rpdutil one also needs ${CRYPTLIBS}, so the rpdutil
target should propagate that to libraries linking against it via the
INTERFACE_LINK_LIBRARIES property, instead of adding ${CRYPTLIBS} to all
libraries linking against rpdutil.

We remove ${CMAKE_DL_LIBS} from the dependencies, since it is now in
${OPENSSL_LIBRARIES} for the builtin openssl, as it is required by
libssl. It would be nice to also use target_compile_definitions instead
of simply add_definitions, but because ROOT_STANDARD_LIBRARY_PACKAGE
does dictionary generation when it's called, it doesn't work.

We need to provide a better match to what a call to
find_package(OpenSSL) gives, to make the builtin work
with CMake 3.9.

Fedora was calling LazyFunctionCreatorAutoloadForModule from rootcling where fInterpreter was not initialized yet.

The buffer tests for histograms have slightly different
rounding errors between buffered/not buffered histograms
which exceed a few epsilons, so the test fails if the
tolerances are too strict.

This allows to error out early, as it was before "[TREEPROCMT] Construct
thread-local chain at event-loop time".

This ensures that the friends of each thread-local TChain know
which tree contains which global entry number without having to
open all intermediate files to check how many entries they contain,
resulting in much less contention in TTreeProcessorMT when multiple
threads are loading the right file to process and friend trees are
present.
This fix partially addresses ROOT-9437.

This ensures that each thread-local TChain knows which tree contains
which global entry number without having to open all intermediate
files to check how many entries they contain, resulting in much
less contention in TTreeProcessorMT when multiple threads are loading
the right file to process.

The new signature will come in handy to let different tasks generate
clusters for different files or sets of files in the future.