fix: Add tests for json-rpc-data and address to describe expected behaviour

[jeffsmale90]

fixes #1594

[jeffsmale90]

I spent some time looking into this today, and have a reasonable grasp on what's going on.

I just wanted to check whether my expectations around the behaviour are correct, so this PR only contains a couple of tests describing that behaviour. Don't expect anything to work, and don't take this as a full and complete set of tests for this behaviour!

Thanks.

[jeffsmale90]

If you have a look at the build, pretty much all of these tests currently fail, except for the first set where no byteLength parameter is passed, as in the current implementation, the byteLength parameter has no impact on the toString() result.

[MicaiahReid]

This looks good! If you implemented these changes I think it will give us a lot more confidence in our Data types. I think the biggest concern is all of the possible side affects this fix could cause. Let's hope our tests are robust enough to catch them!

One more thing to note that I realize as I was digging into the code for the Data constructor. It only allows a value of type string | Buffer, but we only validate against bigint. It might be worth adding extra validation? ¯_(ツ)_/¯

[jeffsmale90]

There's plenty of opportunity to improve this - ie. I tested the performance impact of removing the weakmaps, and it's quite significant, but I wanted to fix the issue without changing too much, with the intention of addressing remaining problems when we rework this.

[MicaiahReid]

Looks good! Tiny nit-picks in the tests.

[jeffsmale90]

Lucky you suggested the change to use getExpectedString - because it didn't truncate properly!

The reason I had a couple of special cases explicitly defined in the tests was to explain the behaviour around truncating / padding. Using getExpectedString instead and adding the 32byte value to the validValues array, I found that the special cases were duplicates, so I removed them and added a comment to the getExpectedString function to explain.

[MicaiahReid]

@jeffsmale90 I added one typo fix to that new comment, but I've approved.