Fix overflow exception on decoding due to negative long field

[asdacap]

• Fix overflow error when storing negative long field (like 0xffffffffffffffff which is -1 when interpreted as signed number)

Changes:

• Decode to long directly

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Other (please describe):

Testing

• Added unit test, confirm exception.
• Fix, confirm no excepion.

Further comments (optional)

• Ideally, the field itself should be changed to ulong, but that seems like a lot of potential issue.

[LukaszRozmej]

I think this might not fix root cause, that we have corrupted receipt encoded. Can we add log values when this happens?

[asdacap]

Not sure if receipt is involved in this case, but nothing really "corrupted" happened here... A header with "0xffffffffffffffff" as gas used was inserted, no issue with encoding so nothing happen. I assume the hash is valid, so it goes to processing, which then determined that the gas used is wrong, so it reject the block, which get recorded by invalid chain tracker, which then get back the header to get it's parent to know the last valid hash. Unlike encoding, the decoding failed, which is what this PR fix.