TriggerZoneMoveTask ignores project lock

[mikkonie]

While looking into #1910, I thought a similar "landing zone queue" could also implemented using LANDINGZONES_TRIGGER_ENABLE and uploading a trigger file - at least if validating AND moving the files is the desired outcome.

Alas, I noticed a bug in the implementation: while we only include landing zones in a non-locking state in processing the file triggers, we don't skip the triggering if the project is currently locked. This means that with multiple zones to be moved, this will generate errors due to the project being locked. It should still work as expected, but all the while generating unnecessary failures in the timeline.

I guess we only tested this with a single active landing zone.

Good thing this is an easy fix, just skip if project lock is currently active.

See also #2042.

[mikkonie]

It seems I'm having problems reading my own code which I wrote years ago. This is in fact correctly handled in the following query:

projects = (
    Project.objects.filter(type='PROJECT')
    .annotate(zone_count=Count('landing_zones'))
    .exclude(zone_count=0)
    .exclude(landing_zones__status__in=STATUS_LOCKING)
)

Oh well, at least this lead me into refactoring the task into something less messy.