var-update-trigger: Update only devices that should be running the release that the image env var is part of

[thgreasi]

The device.should_be_running__release path is optimized w/ the /canAccess() permissions hence this produces a smaller query, which has faster planning & execution time.

It looks like that the previous query was trying to only update devices that already have an image_install, but in the form it was, it was it was also including devices with image_installs that were marked as deleted. So the new approach might actually be saving work.

Didn't add further nested filters on image_installs, in an attempt to keep the query smaller, but I don't think that they are necessary, since it's correct to give trigger an update on a device that has just started downloading a release, but didn't have yet the time to do a state PATCH to create the image_installs.
Moreover, we don't really expect any POSTs or UPDATEs of device service env vars after a release successfully builds anyway.

Change-type: patch

[Page-]

Can you use contains_image to make this match the state get endpoint, and add a comment to the top of this file that the having the queries match the path the state get endpoint uses to get env vars for a device is the way to go. Essentially this captures if a subset of the state-get query will change so the correct thing is to follow the same path (and also means it'll have the same performance characteristics, which we take real care to optimize for in the state-get)

[thgreasi]

Updated the state GET endoints to use the release_image term form
See: #1800
See: https://github.com/balena-io/balena-api/pull/5381
and added the comment that this query should match the state GET paths as discussed.

[thgreasi]

Recheked this query and it seems that this way it becomes as slow as the service_environment_variables one (3+ seconds)...
The mistake was that I used a release id in place of a release_image id in my profiled queries...

[thgreasi]

Marking as draft for now since we shouldn't get it in given that it regresses performance.
Should we reconsider #1794 ?