Implement compression and splitting option in TRestProcessRunner

[nkx111]

Related to #190.

This PR implements compression and splitting option in TRestProcessRunner. The details of these feature can be found in the issue. It also introduces other changes:

1. REST now reads correctly long numbers from rml. see #PR188. pipelines are updated accordingly.
2. test job in ci is moved after build and install job. This avoids warnings of PCM not find(solved in another PR)
3. TRestEventProcess adds a new virtual method NotifyAnalysisTreeReset(). If the file is split, this method will be called.
4. TRestThread no longer inherits from TRestMetadata. This saves memory.
5. restRoot initializes event tree and analysis tree as command line object. They are named as ana_tree0, ev_tree0, etc.

restG4 pipeline for branch nkx111-patch-3 :

[DavidDiezIb]

I splited the EventSelectionProcess pipeline in two parts, with different rml and validation files.

[juanangp]

This is an override of TTree functions? What is the reason of these changes?

[nkx111]

Yes. It is used to read splitted data files. In case multiple files are created to store analysis tree data, we make TRestAnalysisTree running internally with TChain.

[juanangp]

I don't think is a good practise to delete an object which has not been created with new, you can fall in an unexpected behaviour.

[nkx111]

But this is what returned by ROOT. We can only trust that TFile::Get() returns the pointer which is deleteable.

[juanangp]

For sure you can delete the pointer, however root has his own memory management, which means that it can try to access de tree that you just delete, which can end up in a seg fault.

[nkx111]

I don't understand. In which case will ROOT access such object? Or there is any "safe" method provided by ROOT to delete it?

[juanangp]

The tree in fact belongs to the TFile, when the TFile is destroyed it migth try to delete the tree, so you can fall in a double free with an unexpected behaviour.
https://stackoverflow.com/questions/9169774/what-happens-in-a-double-delete

[nkx111]

I did a test and there is no such double free fault if I delete the tree manually. There is also no memory leak if I don't delete the tree. So I guess ROOT has some mechanism to prevent object from file being deleted. Either delete or not is OK.

[nkx111]

But I still need to delete the tree. Otherwise the initializaion of the TChain will be problematic.

[nkx111]

@juanangp Can you approve this PR? I believe those problems are trivial

[juanangp]

Don't quite understand this is this bucle for? Note that you have to delete the pointer content, if not you have a potential memory leak.

Suggested change

	for (i = fThreadNumber; i > 1; i--) {
	// delete (*fThreads.end());
	fThreads.erase(fThreads.end() - 1);
	fThreadNumber--;
	}
	for (auto it = fThread.begin(); it != fThread.end(); ) {
	if( it !=fThread.begin() ) {
	delete * it;
	it = fThread.erase(it);
	fThreadNumber--;
	} else {
	++it;
	}
	}

[nkx111]

I don't know why but it always causes problems when I delete the TRestThread object. This code block is for a rare case that, when adding processes, one process turns out to be must running under single thread. So we remove other threads. I guess this memory leak is acceptable and so I directly comment the delete operation.

[juanangp]

But it was deleted in the previous implementation...

[nkx111]

In the previous implementation this delete operation sometimes causes seg. fault which I don't know why.

[juanangp]

Now that I check more thoroughly, looks like you have a double bucle for fThreads, which can be the origin of the issue.

for (int i = 0; i < fThreadNumber; i++) {
....
               for (i = fThreadNumber; i > 1; i--)

I would suggest to use std iterators instead:

for (auto it = fThread.begin(); it != fThread.end(); ) {