New ZTF alert schema - Forced photometry

[Theodlz]

THe latest ZTF alert schema will now include forced photometry, not included in the prv_candidates array, but in it's own fp_hists array field.

This PR adds the necessary support to ingest that data, and a unit test to verify it.

TODO:

• Compared to prv_candidates, the content of fp_hists changes with time, so it's unclear to me how to best deduplicate that data. For the prv_candidates, we can just use MongoDB's $set operator as the data points are identical (except new ones of course). Here, past data points might not be identical, so that might not work perfectly. Unfortunately, IPAC provides tarballed alert packets for only a night, so hard to test that behavior with little data.

[mcoughlin]

LGTM

[Theodlz]

@mcoughlin for this first PR I settled for the simpler logic:

• update datapoints to use the newer ones when there's any overlap with existing points (as suggested by Russ).

I think this is fine, and easy to implement until we know what most users agree with. Will discuss it this week during multiple meetings with different working groups.

[Theodlz]

Don't mind the +4k lines, it's just the avro files

[Theodlz]

@mcoughlin sorry to bug you again. Got Mansi's input.

She thinks that for now, what is really valuable is mostly forced photometry that comes with the first ever alert for a given object, as it gives us potential detections that pre-date the alert pipeline's discovery of the object. And therefore, updating it is not as important as the prv_candidates, and we can just ingest it for the very first alert and stop there (ignore new forced photometry).

At least until everyone agrees on what is best.

[mcoughlin]

Ok @Theodlz !