Update auto follow-up request priority

[Theodlz]

This PR does:

• when looking for existing follow-up requests, also look if the existing requests are from the same group, and have the same payload.
• if a request exists, but the last candidate passed a filter that yielded a higher priority than the existing request's priority, update it with the new priority value.

Also, a minor change to try to get around the current issues with missing data: When building the "all_prv_candidates"/alert_history list used for ML feature generation, also append the full history of alerts, not just prv_candidates. This should help BTSbot not have high scores on old variables.

A few questions for the reviewers:
@mcoughlin is it correct that updating a request's priority (so effectively, the payload) tells the instrument of the allocation to update it? Just making sure it doesn't just give us the illusion to do so. If that's the case, we might want to delete and recreate instead, which comes with it's own challenges.
-> UPDATE: I checked and it should! At least this is implemented for SEDM's API class.

@nabeelre, given the additional cut on group_id when looking for existing requests, this means that if SEDM has pending or completed requests with either another allocation, or the same allocation but not shared with the auto-triggering group where you have your filter (which should be the case for existing requests), or has a different payload, ... and hasn't been classified and didn't get a spectra, we might still trigger SEDM. Just wanted to make sure that this is the expected behavior. I think it is, given the data access constraints we talked about earlier.

[mcoughlin]

@Theodlz updating should do what it says. If the schedulers don't do that (the just in time ones for sure do) then that is on the schedulers.

[mcoughlin]

LGTM

[nabeelre]

Yup, that logic follows the intended behavior. Commit looks good to me!