DPL I/O API: Supporting spectator vector as return for InputRecord::get<std::vector<T>>

[matthiasrichter]

I'm opening a new PR in order to discuss this topic even though it depends on the commit in #2617

When querying vectors, a spectator vactor is returned which is directly using
the raw memory without copy using polymorphic allocator and spectator memory
resource. A unique instance of the spectator memory resource is kept in the
InputRecord and valid for the lifetime of teh record.

This changes the return type to vector<T const, o2::pmr::SpectatorAllocator<T const>>
and thus breaks compilation in code where the vector with standard allocator is used.

This is not problematic in cases where the returned instance is only used in the
function itself and not passed onto workers (unless in a templatized function call).

Ways out of this problem:
change access to the read-only input data objects in the worker classes

1. where possible one could use a templatized function call, and within this reader
   function use iterators
2. introduce specific vector class like o2::spectator::vector (naming to be discussed)
3. Use spans over the readonly input arrays

Pros and cons:
option 1) (+) can implement flexible code
(-) many of the classes use member variables to hold the
data which are set in advance, implementation must be in the header
this is more an option for small algorithms
option 2) (+) we introduce a data object which can be used system wide
(-) while suitable for the workflow implementations and everything which
is related to messaging in DPL, the worker classes should be kept more
general in order to be used standalone with little overhead
option 3) (+) generic solution
(-) no cons

[matthiasrichter]

Once the worker code is changed to use spans, there is of course also an option to use InputRecord::get<span<T>> for messageable types.

[ktf]

Maybe we should ask that FairMQMessage becomes a "spectator resource" itself, so that we do not need to have separate accounting of those. @rbx @mkrzewic what do you think?

[ktf]

Nevermind the FairMQ message does not know the type...

[mkrzewic]

We have been playing with some ideas at FairMQLevel (see e.g. FairRootGroup/FairMQ#110). btw, the resource does not need to know the type, it is meant to allocate bytes only.

[mkrzewic]

i mean not only, but bytes is enough :)

[ktf]

Ah, I missed resourcebuffer was just "char".

[ktf]

For the record, this PR is fine for me, but I really think we should use spans and string_view when accessing data.

[ktf]

or even the ranges_v3 api...

[matthiasrichter]

A quick update: meanwhile many of the workflows have been adjusted to use spans for the read-only arrays of messageable objects. The span is either retrieved directly from the InputRecord, or a vector of the object is requested in the user code. This PR will in the latter case return vector with SpectatorAllocator and by that avoid a copy. The user code then passes the vector as span to workers, thanks to the constructor provided by gsl::span this is completely transparent.

The second approach can handle both unserialized data and serialized data, while retrieving span directly from InputRecord allows only unserialized data (and will throw otherwise).

The only remaining code to adjust is the TPC CA Tracker now. There the buffering functionality needs to be adjusted.

[ktf]

Is this still needed?

[github-actions]

This PR did not have any update in the last 30 days. Is it still needed? Unless further action in will be closed in 5 days.

[matthiasrichter]

Going to be ready for merging soon, needs #3704 and #3710, and some upcoming changes.

[matthiasrichter]

finally only requiring #3819 to be merged