#20 Architect dealing with communication failures

We need to have a default way to deal with communication failures. This issue outlines what the failure modes are and how to deal with them. In gerenal, in every place where we interpret or wait for content from the other party, we could either get what we want, or we could encounter some kind of error. We should ideally be able to handle most errors in the library code itself and log proper warnings for the user. ## A failure at the networking level - Circumstances: Unreachable host, invalid TLS certificate. - Triggered by: any request the client makes to the server. - Expected behavior: the `_perform_request` method returns a `message_type, message_payload` tuple. - Actual behavior: an Exception is raised - Handling: Log a warning and return ## A failure at the HTTP level Probably a configuration problem or maybe a problem at the opposing server. ## A failure at the OpenADR level An oadrReponse indicating a failure is returned. This should never happen and points to a problem in our library code. The preflight mechanism should prevent invalid messages from being delivered. ## A failure at the signature level - Circumstances: - The message is not properly signed (signature is missing or incomplete) - The fingerprint does not match to what we have on record - The signature is invalid. - Triggered by: Any message that is interpreted by the `parse_message` function. - Expected behavior: `parse_message` returns a `message_type, message_payload` tuple. - Actual behavior: An Exception is raised - Handling: - Log a warning - If this was an incoming message that we need to respond to, return an oadrResponse object.