Publish current source name(s) to status buffers

[david-macmahon]

The current source name(s) should be published to the status buffers. For initial testing, the source name to be published should be derived from the MeerKAT metadata (probably via KATPortalCleint?), but as we start to form beams off-boresight, the source names will be our own.

MeerKAT metadata includes several "target" values that are actually a multi-field custom formatted string. The timing and accuracy of these values is not clear, nor is the format completely understood by us yet (nor is the reason for inconsistencies observed in the values), but presumably there is some way to find out in a timely and accurate way which target the array is going to observe. Alternatively there may be a "source" value that would fit our needs better if only we know about it.

Suffice it to say, getting the source name reliably is currently a but of a conundrum.

[danielczech]

For now, we are extracting the target name from the CBF component's target sensor - it appears to be the most reliable so far (see f8ede2d).

[danielczech]

As noted elsewhere, the value of the above target sensor often seems to arrive a few seconds after the recording commences (and after the observation-activity state transitions to track.
In dda7c76, a slightly different approach was attempted - instead of subscribing to this sensor, its value was retrieved "once off" for each new source in the hope that this would be more reliable. Unfortunately, it seems it still arrives late when testing with the telescope.
One temporary solution would be to return to the "antenna consensus" approach, which did not appear to have these issues.

[danielczech]

Returning to a per-antenna approach (dcde5d2) did not appear to help with the delay in today's commensal test. Perhaps another approach might be to wait for the target name and RA/Dec (str) values to arrive (1-3 seconds) before issuing a PKTSTART.

[danielczech]

Improvements had appeared to mitigate this issue: checking the time of the last capture-start to ensure that the first target of the schedule block is paired with the first track message of the schedule block. However, this appears to be insufficient - there has been at least one incident of stale data (on 2021-10-20) which resulted in the publication of an incorrect SRC_NAME to the processing nodes. Therefore a more reliable approach is needed.

To fix this, for each track message, I plan to have the coordinator check for updates to the target sensor that took place within a certain amount of time (a few seconds) before or after it arrived. Then, PKTSTART will only be sent once a new target name is paired with the current track signal, and SRC_NAME will be correct.