Handle tricky candidate compose fedfind situations better
    
    Talking to @puiterwijk about the tricky corner cases involving
    event creation for candidate composes today made me realize I
    could actually handle it rather better in relvalconsumer and
    wikitcms together.
    
    First off, we don't really need to completely fail event
    creation if we can't create the download page because we can't
    find the fedfind release for the event. We can just handle that
    as a warning and complete the rest of the event creation. This
    is especially true since we can always go back and create the
    download page later.
    
    The other tweaks are to do with the corner cases with candidate
    compose syncing. When candidate composes are produced, they
    appear in the initial compose output location (kojipkgs) first;
    when the 'compose complete' fedmsg appears, it means the compose
    is available there. Shortly after this happens, the compose is
    (or should be...sometimes this fails) imported to PDC. Some time
    after *that* (the time varies at present, as this is triggered
    manually, not automatically), the compose is synced to another
    location, this one in the mirror system (alt/stage). In fedfind
    terms, the compose in its original, non-mirrored location is a
    'Production' instance, while the compose in its synced, mirrored
    location is a 'Compose'.
    
    The validation event version for any candidate compose is based
    on its label, not its compose ID. This happens to be sufficient
    information to determine the *synced* location, but not the
    *unsynced* location. So if all you have is this info, you can
    instantiate the Compose instance for the compose - and thus find
    its images *if it has been synced* - but not the Production
    instance - you can't find the compose's images if it has not yet
    been synced.
    
    To complicate matters a bit, once the compose is imported to PDC
    it *is* possible to get the Production instance from the label,
    because fedfind can query PDC to figure out the compose ID from
    the label.
    
    With all that in mind, there are a couple of changes here. At
    one point in time we had an icky hack to allow relvalconsumer to
    pass a compose ID right into `ComposeEvent.create()` - that
    allowed us to create the event for a candidate compose as soon
    as it was created, before even it was imported to PDC, and get
    a download page with the non-synced image URLs. Here we sort of
    re-introduce that, but in a rather cleaner way: we add a private
    attribute, `ComposeEvent._cid`, which gets populated if (and
    only if) you use `get_validation_event(cid='somecid')` to get
    a `ComposeEvent`. The fedfind release properties are tweaked to
    take advantage of this. If we can't find the `ff_release` from
    the event version information (which could mean the compose is
    done but has not yet been synced), and we have the cid, we try
    getting the fedfind release using the cid instead, and return
    that if it works. Upshot being, we can once again work with the
    `ComposeEvent` for a new candidate compose before it's even
    imported to PDC, and find its images, so long as we instantiate
    it from its compose ID.
    
    The other change is to introduce another fedfind property,
    `ff_release_images`. This one only returns a fedfind release
    instance if it can find one that actually has images; otherwise
    it raises a new error, FedfindNotFoundError. This is partly used
    just to implement the 'skip download page creation with a warning
    if compose cannot be found' behaviour described above, but it
    will also cover another (small) potential corner cases with the
    candidate compose syncing: if the synced Compose 'exists' so far
    as fedfind is concerned, but doesn't yet contain any images -
    which could potentially at least occur during sync - we will now
    catch this, and use the Production instance instead to create
    the download page.
    
    Finally, we extend the test suite quite significantly to cover a
    lot of this ground.
    
    Signed-off-by: Adam Williamson <awilliam@redhat.com>