Default to utf-8 when no encoding type found parsing dogwrap output

[glasnt]

Observation:

When using dogwrap (via a Python 2 pip install) to run commands via cron, in cases where the submit_mode is set to all, it was expected that both stdout and stderr would appear in DataDog. This was not the case.

The event would appear, but the stdout/stderr was lost

The output would appear correctly if the dogwrap command was run in the shell, just not in cron

Cause:

In Python 2, the string from the OutputReader was being inspected for an encoding. If this command was run within a shell, an encoding was found (in this case, ANSI_X3.4-1968). However, when run from cron, no encoding was detected. Thus, attempting to execute a string decode (line.decode(None)) resulted in an error.

In Python 3, the encoding inspection defaults to UTF-8, which is a valid encoding type.

This meant the OutputReader would end up returning no values for stdout/stderr, but the return code and command were still available and sent onto DataDog for client displaying

Solution:

In cases where an encoding type is not identified, default to UTF-8

This will ensure the type is never None, and the default value is used.

An alternative solution to this PR is to not decode if no encoding type is identified, but that might cause more issues down the line.

---

Environment used for debugging and code testing: Ubuntu 16.04, Python 2.7.12/3.5.2

[yannmh]

Thanks for the detailed description of the problem @glasnt. I believe this is related with #55.

Setting the default encoding type to UTF-8 sounds reasonable to me.