PyGRB: Update postprocessing functions

[jakeb245]

This PR is another step in resolving #4419. It should finish off converting the backend parts of the old XML functionality into HDF. The functionality is intended to be the same, but there could be some cases in here where it should be changed.

[jakeb245]

I think the issue keeping this PR open is what information about templates should be written into the output files. I'm told the main PyCBC searches only write the template ID, and then go back to the template file to get that information. I've started to break this convention in the current state of these code changes by writing the template masses to the trigger output files.

The template ID that is currently written in the WIP PyGRB code is effectively an index of the split template file. Using this would require us to keep track of the thousands of template files which does not seems like a great idea. I'm thinking the best way to go about this is to write the template hash in place of the template ID, which would allow us to find the templates in the full template bank in postprocessing.

Pinging @pannarale and @titodalcanton for discussion. I'd like to have a bit of input before trying to code this.

[titodalcanton]

@jakeb245 yes, I would use a similar approach used by pycbc_inspiral in the all-sky all-time search, which indeed consists in storing just the template hash for each trigger after matched filtering. To be precise, the following happens there:

1. pycbc_inspiral does matched filtering for each bank split separately, and the corresponding triggers store the template hashes only.
2. pycbc_coinc_mergetrigs then takes all the triggers from all the bank splits from step 1, merges them together, and uses the template hashes to recover the template IDs into the full bank.

Have a look at this documentation page for more info: https://pycbc.org/pycbc/latest/html/formats/hdf_format.html. You can also see an example of this by looking at the various files from one of the all-sky all-time O4 chunks, in particular you want to look at one of the full_data/*-INSPIRAL_BANK*.hdf files for step 1, and full_data/*-HDF_TRIGGER_MERGE_FULL_DATA*.hdf for step 2.

Ping me on Slack if more is needed.

[titodalcanton]

@jakeb245 I had a close look at this PR. As you know I am a bit removed from the development of this code, so I left a bunch of questions above to fill some gaps in my understanding, but I do not see anything too concerning here. I am happy to approve this once you have answered the comments.

[titodalcanton]

I think there are a couple things to fix (noted above), then I think this can go in.

[titodalcanton]

I am still not super convinced that I understand the logic of the slide_id/event_id thing here, so whoever is developing that functionality should keep it in mind. But let's merge this and continue developing.

I think this has been addressed