Empty stashes can be created and published when a block is submitted for an unsigned file

[willdurand]

STR

1. Locally, find an add-on that doesn't have a version with a signed file (such
   as the ones generated by default)
2. Hard-block that add-on
3. Run ./manage.py cron upload_mlbf_to_remote_settings

Expected

No stash record is created/published.

Actual

An empty stash record is created/published in Remote Settings:

{"blocked": [], "unblocked": []}

This is "easy" to reproduce in localdev, not sure how we'd reproduce this in our
hosted envs, especially in somewhat realistic conditions.

Note that re-running Step (3) will NOT create another empty stash. This only
happens once. I suppose some state/time is persisted somewhere. That might be
something to keep in mind when fixing this bug.

┆Issue is synchronized with this Jira Task

[KevinMind]

I can verify this as well. STR for me after following setup

from olympia.blocklist.models import BlockType
from olympia.amo.tests import addon_factory, block_factory, version_factory

def _blocked_addon(block_type=BlockType.BLOCKED, **kwargs):
    addon = addon_factory(**kwargs)
    block = block_factory(
        guid=addon.guid, updated_by=user, block_type=block_type
    )
    return addon, block

user = UserProfile.objects.first()

_blocked_addon(block_type=BlockType.BLOCKED, file_kw={'is_signed': False})

Then in a shell run

./manage.py cron upload_mlbf_to_remote_settings

Expect the stash in the latest filter to be

{"blocked": [<Your addon hash>], "unblocked": []}

Actual:

{"blocked": [], "unblocked": []}

[KevinMind]

The root cause of this issue is here

previous_filter.created_at < get_blocklist_last_modified_time()

If a block is created for an unsigned addon, it is still makes the last modified time more recent than the previous filter.. this triggers an update with an empty stash.

This PR fixes that issue, but maybe not in the right way. We could consider fixing by updating the query for blocks associated with signed files.. maybe searching for versions.. or even getting rid of this condition as it's not totally clear that it is valuable anymore as we will rely on the database state to determine if we should update the filter

[diox]

The fix from the PR is probably good, but we should prevent this from happening in the admin (and even model) in the first place: there is no need to block unsigned versions, that's kinda pointless as the signature is what makes blocklisting them reliable.