Don't attempt to make decisions from old-style compose fedmsgs
    
    This is effectively a reversion of 414d392 (PR #262). That
    attempted to 'fix' greenwave to make compose decisions based on
    the old-style taskotron.result.new messages with type 'compose'.
    In fact, however, it was *intentional* that greenwave does not
    do this, because it is not possible to do it reliably. These
    references have the back story:
    
    https://pagure.io/greenwave/issue/122
    https://pagure.io/taskotron/resultsdb/issue/92
    https://pagure.io/taskotron/resultsdb/pull-request/101
    https://pagure.io/greenwave/pull-request/262#comment-70350
    
    For compose tests, Autocloud reports the 'item' as the image it
    is testing. Some openQA tests report the 'item' as the image
    under test, and some report the 'item' as the compose ID. Thus
    you can never actually find all the results for a given compose
    by searching for a given 'item'. In order to find all results
    for a given compose, you must search for results with the extra
    data key 'productmd.compose.id' set to the compose ID, because
    *all* compose results *do* have that.
    
    Old-style 'taskotron.result.new' fedmsgs, however, do not have
    the extra data keys; they only include the 'item', 'type' and
    'name', so far as identifying information goes. For a message
    like the one added as a test in the initial commit (and kept as
    a test here, with a different expected outcome), where the item
    is not the compose ID, we simply cannot possibly discover all
    the other relevant results. If the 'item' *happens* to be the
    compose ID, we could use it to find all relevant results with a
    ResultsDB query for `productmd.compose.id` (though we still
    couldn't find all relevant results in the message cache), but
    that doesn't really seem worth trying to support.
    
    The new-style 'resultsdb.result.new' fedmsgs that were added
    by https://pagure.io/taskotron/resultsdb/pull-request/101 *do*
    always include the extra data. So we *can* reliably find all
    relevant results if we're working with that message format, and
    that's what we were actually intending to do. We just never, it
    seems, flipped the Fedora greenwave instance over to using the
    new message format instead of the old one.
    
    So in the end we should just revert the change, which restores
    the correct behaviour of only attempting to handle compose
    decisions when we have productmd.compose.id, and add tests for
    the intended behaviour and better comments, so no-one ever has
    to go through this again! I will also try and get the Fedora
    deployment's config changed so it works from new-style messages
    instead of old-style messages; if we do this, it'll actually
    publish *useful* compose decisions.
    
    Signed-off-by: Adam Williamson <awilliam@redhat.com>