SP addressing has TOCTOU race

[davepacheco]

Clients of MGS address service processors by type and slot number (e.g., /sp/sled/10), which I think corresponds to cubby numbers (or maybe more precisely: backplane cable numbers). But these can presumably change over time (e.g., if an operator moves sleds between cubbies) and I don't see a way for a client to avoid accidentally sending a command to the wrong SP.

Concretely, if a client is looking to turn off a particular sled (that they know by its serial number), they might:

1. for each slot, use GET /sp/sled/$slot to see which sled is in which slot and store this
2. pick the slot that reported having the sled it wants to turn off
3. use POST /sp/sled/$slot/power-state to move the sled to A2

But if an operator has moved the sled between cubbies between steps 1 and 3, we might turn off some other sled!

---

@jgallagher and I talked about a few ways to deal with this. I think in order to avoid the time-of-check-to-time-of-use race, the SP has to be involved in verifying that the request is intended for it. MGS could include in its messages to the SP some identifier that the SP can reject if it doesn't match its own identifier. This identifier could maybe be the serial number, or it could be some made-up identifier that MGS has previously assigned to the SP (which would presumably need to be re-sent by MGS if the SP restarts).