String/Bytes fix

[RedProkofiev]

Resolves #146
Resolves #209

The PR adds a new test which sends bytestrings through on_message, and through the test isolated two different issues with bytestring handling:

 if 'application/pkcs7-mime' in text or 'application/x-pkcs7-mime' in text:
            try:
                text = crypto.decrypt(text, self._cert, self._key)
            except crypto.CryptoException as e:
                error = 'Failed to decrypt message: %s' % e
                log.error(error)
                return None, None, error

In _handle_msg, the string comparison with 'in' would trigger a byte-not-str error,

 log.warning("Message rejected: %s", err_msg)
 name = self._rejectq.add({'body': body,
                                          'signer': signer,
                                          'empaid': empaid,
                                          'error': err_msg})
 log.info("Message saved to reject queue as %s", name)

In _save_msg_to_queue, errors would be caught by the IO/OS error handler, but removing that showed that the raw bytestring from 'body' was being placed into Dirq which handled it as if it was a string causing a decode error.

Our Dirq schemas suggest that we only want strings in this point. I added a ducktype test that solves both problems in _save_msg_to_queue.

[RedProkofiev]

Can confirm, works with python 2.

[tofu-rocketry]

Can confirm, works with python 2.

Except note the Travis CI failure with Python 2 - test_ssm.py needs a Unicode declaration at the top.

[tofu-rocketry]

Actually sending the test string via AMS works in 2 & 3, using directory as the queue type only.

Receiving doesn't work in 2 (but does in 3).

2024-02-07 12:56:17,077 - ssmreceive - ERROR - Unexpected exception: 'ascii' codec can't encode character u'\xe9' in position 275: ordinal not in range(128)
2024-02-07 12:56:17,077 - ssmreceive - ERROR - Exception type: <type 'exceptions.UnicodeEncodeError'>
2024-02-07 12:56:17,077 - ssmreceive - ERROR - The SSM will exit.

[tofu-rocketry]

Oh, I should test dirq sending rather than just directory, as the former was reported as the issue in #270.

[tofu-rocketry]

Ok, adding UTF-8 into the mix here was hiding the issue that the original tickets reported. And testing using directory rather than dirq worked around the original issue.

The problem is the lack of strict encoding and decoding at the program boundaries. This does also mean that there's a choice to make about codec to use, but need to be careful not to break the APEL loader.