Consolidate Firmware TTL logic

[mobileoverlord]

Firmware TTL is a mechanism for marking firmware eligible to be garbage collected after a certain time. This determination is made whenever the number of associations a firmware has goes from 0 to 1 or > 0 to 0. Currently, firmware can have associations with devices and deployments. The logic to check if firmware becomes eligible or not also exists at those sites. We should see if there is a cleaner way of consolidating the spread of this logic in case we add or remove other associations with firmware in the future.

[ConnorRigby]

So i don't have much of a solution to add to this, but I thought I'd chime in anyway with what my ideal TTL system might be for my particular use case.

I have three major branches on my project:

• master - Should be the most stable
• beta - Should be almost stable
• staging - Pretty frequently broken

I have CircleCI deploying each of those branches upon a push. (after tests etc).
master and beta both don't really have a TTL since they are accompanied by a tag in git, but staging has a low TTL. I pretty much only ever want one firmware associated with staging, but the association of device can prevent the firmware from being garbage collected if a device is offline from what i understand. I think this kind of goes back to #282 and sort of this issue also on the nerves-hub repo.

if the association of firmware to device were set to on_delete: :nilify (that might not be the correct syntax), and we allowed a "default" firmware for unknown uuids on a device maybe, or maybe a fallback deployment if a device doesn't match any known firrmwares or tags?

Anyway this is just my 2 cents. Open to other suggestions as my ideal solution might not match up to others'.

[fhunleth]

The TTL logic is in one place, so this issue is "fixed".

@ConnorRigby Do you still have things that you want updated on the TTL logic. If so, let's get them in additional issues.