fix: claim update slot atomically

[timkambic-ngen]

While working on #425 I noticed the non atomic update slot handling. Which I introduced in #290

We have seen the max_concurrent_updates limit being breached quite a lot on our deployment. Especially when a new rollout is triggered and all devices compete for the slots.

This PR introduces a new state RESERVED which is atomically claimed and assigned to a device. After the device reports progress it's state is changed to RUNNING - same behavior as before.

Note: I have also considered to change device's state directly to RUNNING as soon as the slot is claimed but it introduced quite some behavioral changes.

[timkambic-ngen]

Tested this also in our production setting with lots of devices. Before it would overshoot the configured max_concurrent_updates limit of 50 by 10-15devices on new rollout trigger.
Now it correctly limits to the configured amount of slots

[b-rowan]

Any chance we can avoid the raw SQL? If not then this is fine as is, I will approve and merge, just want a sanity check, and my SQL skills are not great.

[timkambic-ngen]

Any chance we can avoid the raw SQL? If not then this is fine as is, I will approve and merge, just want a sanity check, and my SQL skills are not great.

Dropped the raw sql and used tortoise. Looks cleaner