ITS: skip processing entirely if no clusters/rofs in TF

[f3sch]

Should fix the error reported in https://its.cern.ch/jira/browse/O2-6264 for test 1.
The issue seems to be that sometimes there are TFs which do not contain any digits/rof information for ITS.
The cpu code handles this correctly the gpu code does not since it tries to then to pin empty buffers.
This fixes this by entirely skipping any processing if there are no clusters/rofs received.

[3403294:its-clusterer]: [10:28:20][INFO] ITSClusterer pulled 0 digits, in 0 RO frames
[3403294:its-clusterer]: [10:28:20][INFO] ITSClusterer pulled 0 labels
[3403296:its-tracker]: [10:28:21][INFO] ITSTracker pulled 0 clusters, 0 RO frames  -> received no processable data will skip

I tested that downstream devices that use ITS track info handle this situation by running the pvertexer just on ITS (is this enough as a test?).

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

[shahor02]

In every run the first few 100 TFs have ITS empty: the data are discarded during the ROF rate ramp-up.

[f3sch]

What do you mean with discarded since Catalin used this data for an async-like pass, I assume we still fully process this data?

[shahor02]

What do you mean with discarded since Catalin used this data for an async-like pass, I assume we still fully process this data?

We do but with empty ITS the AOD contains no vertices. This affects 1st couple of seconds of every run.

[f3sch]

ah ok of course, I misunderstood your comment, thanks!

[fprino]

It seems to me that this protection does not hurt, even though from Ruben's comment it may not be necessary. Nevertheless, Felix checked that it fixes locally the crash on GPU reported in https://its.cern.ch/jira/browse/O2-6264. So. I would be in favour of merging it and run a new test