Correctly calculate cpu_seconds for processtree

[berland]

If a subprocess in the processtree terminates early, its cpu_seconds value will be lost unless we keep all values pr. pid until the end.

Since pids can be reused (although with little probability) we need to detect this through a decreasing cpu_second value for a pid that has already been observed in the processtree.

The test has been modified in order to trigger this scenario.

Issue
Resolves #9941

Approach
🗒️ Do the book-keeping necessary.

• PR title captures the intent of the changes, and is fitting for release notes.
• Added appropriate release note label
• Commit history is consistent and clean, in line with the contribution guidelines.
• Make sure unit tests pass locally after every commit (git rebase -i main --exec 'just rapid-tests')

When applicable

• When there are user facing changes: Updated documentation
• New behavior or changes to existing untested code: Ensured that unit tests are added (See Ground Rules).
• Large PR: Prepare changes in small commits for more convenient review
• Bug fix: Add regression test for the bug
• Bug fix: Create Backport PR to latest release

[codspeed-hq]

CodSpeed Performance Report

Merging #9943 will not alter performance

_{Comparing berland:correct_cpu_seconds (14c9939) with main (7c27a9c)}

Summary

✅ 25 untouched benchmarks

[eivindjahren]

You could extract this part to make it easier to test:

@dataclass
class CpuTimer:
  _cpu_seconds_pr_pid: dict[str, float] = field(default_factory=dict, init=False)

  def update(self, cpu_seconds_snapshot):
    ...

  def total_cpu_seconds(self):
    return sum(self._cpu_seconds_pr_pid.values())

Then you can easily test the logic by giving it fake cpu_seconds_snapshots.

[eivindjahren]

I had a small suggestion about improving the testability of the logic, but I see no need to block merging. The suggested refactoring and adding of testing can be done in a separate PR.