- using webmock instead of mocking Net::HTTP
    therefore removing the connascence between the spec and the
    HTTP lib used in the implementation, thank you Teddy

Return `true` from this method by default. If the `#update` call fails,
then it will return `false`, but in all other cases, we should return
`true`. That way, when the
`Api::V1::ComplianceCheckSetsController#validated` endpoint is called,
it will respond with the `ComplianceCheckSet` object instead of:

    {"status":"error","messages":[]}

with no error messages.

Refs #4757

If any associated resources have the "IGNORED" status, this shouldn't
affect the outcome of a "successful" status. Allow the
`ComplianceCheckSet` to be "successful" even if some `Resource`s are
"IGNORED".

Refs #4757

We should return the result of the `ActiveRecord` `#update` call, so
that we can determine if there was an error saving the
`ComplianceCheckSet` record.

Refs #4757

This reverts commit b7477e28f90c961079c7b12c4992071cbc11b2d6.

This logic isn't right. We should return true/false based on the result
of `update`, as in, whether the value was able to be updated, instead of
on the contents of the status.

Ensure that `#update_status` always returns a boolean value. We'll be
using this to determine whether the updated status was 'successful' or
not. Hmmm. Wait. That's not right. We want to return true from the
update, we don't care about the status. The error case should be when
the `update` fails. Darn.

Refs #4757

Move the successful `ComplianceCheckResource`s to the end so that these
tests fail if we don't wait until the end of a loop through the resoures
before updating the status to 'successful'.

Refs #4757

Add test cases for status update when `ComplianceCheckResource` are
"ERROR" and "WARNING". If a single Resource is "ERROR" or "WARNING",
then the `ComplianceCheckSet` becomes "failed" or "warning".

Refs #4757