Fixed invalid UTF-8 sequence in tests -- all tests passing

[tvincentNuoDB]

Decimal sequences longer than 9 bytes are now handled by putScaledCount2, before they were sent under the decimal protocol which would cause an invalid utf-8 sequence upon receiving. A few minor Python 3 fixes to putting data were made as well

[landscape-bot]

Code quality remained the same when pulling 8b50611 on tvincentNuoDB:master into 53ef0ce on nuodb:master.

[mjmichaels]

I don't understand this change. Let's talk more about it tomorrow. valueStr is a string of digits right? So we are sending edsScaledCount2 for a string longer than 9? Normally it takes I think 20 digits to need an edsScaledCount2. Maybe I am missing something.

[tvincentNuoDB]

Sure thing, it would seem the issue is the way python handles sockets as byte strings are the only thing a socket can send. Before they used

     chr(protocol.SCALEDLEN0 + len(valueStr))

This starts us off with the base value of ScaledLen0 and you will add 1 for each character present in the string. The issue is they never checked overflow with ScaledLen8. So if you put something 10 numbers long or longer, it will overflow into the next protocol. I'm not sure if this is the best solution for sending numeric values in the first place

[landscape-bot]

Code quality remained the same when pulling 0217e00 on tvincentNuoDB:master into 53ef0ce on nuodb:master.

[tvincentNuoDB]

Fixes issue 65