Migrate fill info retrieval to the new LHC plugin

[knopers8]

This commit adds a new call in LHC plugin which updates a given environment with the latest known fill information. Once we validate it, we can proceed with switching off the bkp.RetrieveFillInfo() call. A necessary change in workflow template will have to follow.

This approach is better, because we don't rely on a man in the middle, thus reduce risks of errors and getting the required info too late (i.e. not before SOR).

Closes OCTRL-1057

[justonedev1]

I approve this but I am not sure whether all of the global variables are set/reset correctly, but I trust you that they are.
However I have one question about timestamps. We are receiving timestamps about beam via kafka, so it means that when we reach stable beam we get new message with stable beam start and no end, right? And when the beam is dumped, we receive what exactly?

[knopers8]

I approve this but I am not sure whether all of the global variables are set/reset correctly, but I trust you that they are. However I have one question about timestamps. We are receiving timestamps about beam via kafka, so it means that when we reach stable beam we get new message with stable beam start and no end, right? And when the beam is dumped, we receive what exactly?

From my observations, when SB did not happen, we get "-1" as timestamps:

1: 1763377322000
2: 1763377322000000000
200: {
  1: 1763377322000
  2: {
    1: 18446744073709551615  # SB start
    2: 18446744073709551615  # SB end
    3: 11307
    4: "100ns_432b_374_250_181_28bpi_27inj_VdMPbPb"
    5: "PB82 - PB82"
    6: 10
  }
}

When we enter SB, we get:

1: 1763377797000
2: 1763377797000000000
200: {
  1: 1763377797000
  2: {
    1: 1763377797000 # SB start
                                      # missing optional value for field 2 - SB end 
    3: 11307
    4: "100ns_432b_374_250_181_28bpi_27inj_VdMPbPb"
    5: "PB82 - PB82"
    6: 11
  }
}

When the beam is dump, we get both SB start and end:

1: 1763362867000
2: 1763362867000000000
200: {
  1: 1763362867000
  2: {
    1: 1763357281000 # SB start
    2: 1763362805014 # SB end
    3: 11305
    4: "50ns_795b_642_642_400_56bpi_18inj_3INDIVs_800ns_bs100ns"
    5: "PB82 - PB82"
    6: 16
  }
}

So the "-1" vs. missing optional value is somewhat inconsistent, but we support both cases for missing values.