Re-define transfer_id as struct{task_id, buffer_id, reduction_id}

[fknorr]

This is another back-port from IDAG development.

The transfer_id is used to match incoming MPI transfers to await-push commands. Previously this was an integer encoding of "task + chunk id", which together with a buffer_id, and (optionally) a reduction_id uniquely identifies an await-push on the target node.

It turns out that instead of the "magic" chunk id, the task id is sufficient. This PR bundles it with the buffer id and reduction id such that struct transfer_id now uniquely identifies the receiving await-push, improving readability of logs / dot graphs and avoiding repetitions of (transfer_id, buffer_id, reduction_id) in the code.

[github-actions[bot]]

Check-perf-impact results: (4c65f1399a47e0eb1340f63004745b17)

:question: No new benchmark data submitted. :question:
Please re-run the microbenchmarks and include the results if your commit could potentially affect performance.

[fknorr]

Bikeshedding, from an in-person discussion with @psalz: transfer_id might not be a good name because it does not uniquely identify a transfer: There can be multiple transfers per transfer_id on each node (for different subregions) and the same transfer_id + region can exist multiple times in the cluster if the same data is sent to more than one node.

How about buffer_version or buffer_version_id (see source comments)?

[coveralls]

Pull Request Test Coverage Report for Build 7775009065

• 0 of 63 (100.0%) changed or added relevant lines in 11 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.02%) to 93.877%

---

Totals
Change from base Build 7727056751:	0.02%
Covered Lines:	4997
Relevant Lines:	5195

---

💛 - Coveralls

[psalz]

How about buffer_version or buffer_version_id (see source comments)?

I feel like a "buffer version" would have to contain the last writer task id, not the consumer task id. Otherwise two reading tasks that require the same data written by an earlier task would receive two different "versions", even though it's the same data, which seems weird to me.

[fknorr]

From in-person discussion: We're leaving the name as-is for the moment to avoid rebase pain in the IDAG branch, and in the hope that documentation will make up for the imperfect name.