[PWGCF] Update flowEventPlane.cxx

[yashpatley]

1. Added track table to fix previous error of table size mismatch
2. Added v0 flow

[github-actions]

O2 linter results: ❌ 0 errors, ⚠️ 0 warnings, 🔕 0 disabled

[victor-gonzalez]

I guess there are no plans of using stored derived data
Why then recreate and store information that is already available in the Tracks tabel?

[yashpatley]

Dear Victor,
This is because I added the pion, kaon, proton flags in the table earlier. But there was a size mismatch issue when I was joining it with the track table. This was because of the Collision selection condition in the process. I wanted the identified tags so I can use them to reconstruct resonance later in another workflow. The reason I modified it this way is because when I composed the wagon on HL for large dataset it showed memory warning. And it was because of the track combinations. So with the identification and a partition I was able to reduce the memory consumption. That's why this way. Also, I discussed with Debojit and we plan to use derived data in future from the large data set for tracks and collisions with zdc flow vectors. Let me know if changes are required.

[victor-gonzalez]

Well, the memory usage will increase quite a lot if the Tracks table is replicated in memory which is basically what this PR is doing. The right way should be a table with just the additional information needed but joinable to the Tracks table. For doing that all the tracks should have proper information in this additional table. By proper information I mean consistent information for the considered analysis, i.e., if the track should not be included in the analysis, its entry in the additional table should have a value which identifies such situation (perhaps false for pion, proton, and kaon flags?)

[yashpatley]

Dear Victor, please have a look at the new update to this PR. Thanks. Please let me know if there are further suggestions.

[victor-gonzalez]

Have a look at may comment in case you want to consider it (it will decrease the CPU consumption)

[victor-gonzalez]

I would suggest this construction

if constexpr (partType == kPi) {
  // additional conditions for pions setting the retFlag
}
if constexpr (partType == kKa) {
  // additional conditions for kaons setting the retFlag
}
if constexpr (partType == kPr) {
  // additional conditions for protons setting the retFlag
}
return retFlag;

In that way the compiler will generate the corresponding copy of the routine and the protons will not always suffer two unsuccessful ifs

That's the magic of the template mechanism