Include RapidPE-RIFT pastro in second preliminary alert

ligo-followup-advocate==1.2.7 can include RapidPE-RIFT pastro in the update circular. To include this in the second preliminary alert(5-minute preliminary alert), we need to address the scenario where the preferred event changes after RapidPE complete the pastro calculation.

RapidPE produces an update to the search pipelines' pastro source category probabilities based on parameter estimation, assuming that a signal is present. Part of RapidPE's pastro data product includes the Pterr estimate copied over from the preferred event's Pterr from the search since RapidPE does not calculate Pterr itself. The source category probabilities in RapidPE are then re-weighted according to the value of Pterr to produce the pastro json and png files. Because all this happens on a timescale of a few minutes, it is possible that the preferred event may change after RapidPE has finished producing the updated pastro files. In this case, to provide the most updated value of Pterr along with the updated source category probabilities, Pterr would need to be updated in the RapidPE Pastro files, and the source categories re-weighted again based on this new value of Pterr.

We propose that the source category re-weighting should be performed within gwcelery as a solution to this problem. This would involve writing a function in rapidpe-rift-pipe which takes the json dictionaries of RapidPE's pastro and pipeline pastro as input and produces an output Pastro json dictionary including the Pterr of the preferred event trigger along with the re-weighted source categories (P_BNS, P_NSBH, P_BBH). We need to apply changes within gwcelery to call this function when building alerts and uploading the re-weighted RapidPE Pastro files to gracedb. When this data is used in an automatic alert, the re-weighted Pastro will be tagged as public by gwcelery.

rapidpe-rift/rapidpe-rift-pipe!159 (merged) adds a new function to reweight pastro files in rapidpe-rift-pipe.