Use pregenerated injection frame file to perform pregenerated injections (resurrected)

[spxiwh]

Standard information about the request

This is a: new feature

This change affects: the offline search, inference, PyGRB

This change changes: scientific output

This change: has appropriate unit tests, follows style guidelines (See e.g. PEP8), has been proposed using the contribution guidelines

This change will: add new functionality, but not break anything

Motivation

This is an attempt to resurrect #4477. In the past it has been difficult to guarantee that different search codes are making identical injections, and therefore comparisons can be hard. In addition some newer injection waveforms can require huge amounts of RAM, making it difficult to set requirements for jobs running on OSG. Using pregenerated injection frame files fixes this and such files can be easily distributed over OSG

Contents

We add the ability to add injections from frame files containing pregenerated injections (... I note that one could put anything in these files, so if you wanted to inject cosmic string blip direct collapse non-GR mergers this would be the easiest way to do that).

Links to any issues or associated PRs

This is taken from #4477 I've resurrected the code and reworked a few things.

Testing performed

I will need to test this on pregenerated injection frames. The CI will test it in "normal" settings.

Additional notes

@ahnitz Had some comments on the original PR. Some responses here:

• Regarding the generate_injections option in InjectionSet.apply(). I think it is not the right approach to not call InjectionSet.apply() if not generating injections, but still wanting to filter them. All our injection optimization (when not to analyse segments, times, templates etc. is based on information that comes from here when we read the injection files. Actually making the injections is one line (which we bypass if this is set), but all the rest is still needed. We're basically already doing this in the minifollowups where we use the hack of setting injection_scale_factor to 0 to acheive exactly the same thing. That can now be done "properly" ... reminding that we do want to not generate injections when using these frames because of high memory usage of some injection models.
• Duplication in strain.py's from_cli module. There is similarly between injection_frame reading and normal frame reading. I avoided further duplication by adding the two together immediately after reading the injection frames. I'm okay with this duplication ... The from_cli function could do with a cleanup and consideration of structure (might be nice to be flexible about the order in which things are done), but that feels out of scope of this.

I think other issues are addressed.

• [./ ] The author of this pull request confirms they will adhere to the code of conduct