Add new strategy for getting on GRB bursts early

[martinjohndyer]

Something like 5 sets 12x10s.

Valid for first ~15 minutes after the burst.

Want to skip refocus to save time? https://github.com/GOTO-OBS/gtecs-control/issues/660

ADD EXTRA NOTES

[martinjohndyer]

So I've been back-and-forth a bit on this, because it requires some changes to the underlying system.

The idea is simple: we have some rapid exposures if we can get on early, and if not we fall back to the normal strategy.

In fact we've been though this before, it's pretty similar to what I added in #52 and then removed in #75 for Swift and Fermi short alerts. We had the HAMMER_EARLY cadence to take observations quickly and then the FOLLOW_LATE cadence to fall back to later. There was a load of changes to enable multiple cadences for a given strategy, and at the time we were just using the old Mpointing structures in the ObsDB. To get it to work properly when we moved to the multi-telescope system I implemented an actual Strategies table (https://github.com/GOTO-OBS/gtecs-obs/issues/83) in https://github.com/GOTO-OBS/gtecs-obs/pull/84, which allowed Targets to switch strategy after a given time. And it worked, but a year later the GRB WG decided that was actually too much, and since #75 we've stuck to a single cadence and strategy for each event. All that effort...

So now we have another proposal, again for a different strategy if we can get onto the target early. This time however it's even more complicated, because we want different exposure sets depending on how quickly we can observe. I could see allowing notices to pick multiple strategies, something like GRB_RAPID;GRB_SWIFT where both GRB_RAPID and GRB_SWIFT are defined in the strategies JSON. But the issue is that in https://github.com/GOTO-OBS/gtecs-obs/pull/84 I linked ExposureSets to Targets, but this would essentially require them to be linked to Strategies instead, so that the early strategy could take 12x10s sets and the later strategy the normal 4x90s. We might also want a higher rank for the initial observations, and that's also on to the Targets table not Strategies. So this would mean yet another series of changes to the ObsDB, which would be a pain.

Having looked through the alert code, I think there might be a way around that by creating multiple Targets, so going back to the old system. It's unsatisfying, but in the handler we'd create new Targets for each strategy. We can keep allowing a given strategy to have multiple cadences, which would mean multiple Strategies on the same Target as before. But this way we could have things that are linked to the Target change. The tile selection parameters are a bit of a pain though, if they change then we'd have different sets of targets which should be different Surveys. Actually is that the way to do it, have a unique Survey per strategy? It really would be a lot of duplication though.

To be honest, as I'm writing this out it feels more like the "correct" thing to do is definitely move the rank and ExposureSets to the strategies table. If it's the same set of targets then we should only have one Target, and the Strategies are designed to handle these sort of changes. We should only need multiple Surveys if the actual set of targets change, e.g. with an updated skymap.

So I've convinced myself, this needs a gtecs.obs issue... EDIT: https://github.com/GOTO-OBS/gtecs-obs/issues/99

[martinjohndyer]

I never got around to adding this into #91, since it's waiting on https://github.com/GOTO-OBS/gtecs-obs/issues/99 which is a bit of a pain. So it's still a todo for now.