DF/data4es: events calculation v2.

[mgolosova]

New algorithm of calculation for these values was suggested by M.Borodin Mikhail.Borodin@cern.ch during a discussion on "how to get current progress info for a task from DEFT" as the "most general" one.

There can possibly be some cases not addressed in the current version, but they are to be detected when we start collecting and using the data.

---

Waiting for: #368 (parent task metadata).

ToDo:

• rebase after DF/data4es: add parent task metadata (p_taskname, p_total_events). #368 (for it will be changed after Merge REST API server branch to master #176) (merged, not rebased) (and then rebased)

[mgolosova]

Расширение data4es для данных по прогрессу обработки событий

[mgolosova]

First I tried to simply merge master here, but the branch this one was derived from was rewritten (rebased on a more actual master), so there was an extra commit duplicating the one that was already in master with different id.

mgolosova force-pushed the data4es-017-events-calculation-v2 branch from a078a6e to a10cc71 16 minutes ago

Here I fixed the merge commit (messed a bit with the mapping conflict resolving and in addition to the conflict resolution fixed codestyle).

mgolosova force-pushed the data4es-017-events-calculation-v2 branch from a10cc71 to a16ae65 17 seconds ago

Here I rebased current branch to the master and thus get rid of multiple identic commits in the history.

It was a good idea to stay away from rebases and push-forces, but, unfortunately, one rebase has already happened -- and now we have to follow this paradigm to avoid extra mess in the resulting commits history in master.

[Evildoor]

It took some time to verify the logic, but it seems to be correct according to trello, emails, and "Mikhail said so". Hence, only two text-related comments remain.

[Evildoor]

Foreword: this comment is just a bunch of thoughts about the situation that was already discussed in #368, so it does not call for changes in this PR, and may be left without answer.

---

This means that this function MUST be executed after chain data handling in transform_chain_data(). It's indeed coded this way, so if the said function correctly processes the data then there should be no problems. However...

1. What if something actually goes wrong?
2. If the chain roots are now receiving this special treatment, then it's another reason to think about "Is it a good idea to designate a task as a root of its own chain if something goes wrong?".

[mgolosova]

1. If something goes wrong (as in “there’s no taskid or chain_id), then we can not calculate values we need properly, and, in fact, there’s something completely wring about given message. If it’s a one-time accident, we fail now and try again later when the process restarted. If we keep on failing at this record than it’s not an accident and we need to take a closer look at the data and decide how to handle it. When it’s no longer a hypothetical “what if”.

2. This”special treatment” means “we need to know if this task is a first in chain or not. If we don’t know for sure, but set chain_id to taskid, here we’ll think that it is first, although it might as well be the opposite. I believe it would be incorrect.