Add ABI encoding support

[ahangsu]

Corresponding implementation to algorand/go-algorand#2807

• serialization/deserialization of ABI types (and the corresponding testing)
• Encoding/Decoding of JAVA values with ABI type schemes (with tests)

Closes #244

[jasonpaulos]

This is a good start, and I really like the approach of having a base Type and Value class and subclasses for every ABI type. It seems like it will be easier to add new ABI types in the future with this approach.

However, I would suggesting changing the subclass names from <abi-type>T and <abi-type>V to Type<abi-type> and Value<abi-type>, e.g. TypeUint and ValueUint.

[algochoi]

This is looking very clean, just left some minor initial comments.

[jasonpaulos]

The more I think about it, the more the Python/Javascript approach of having no Value classes makes more sense to me. With the current implementation, this is the code needed to encode a value of type (uint64,byte[]):

Value intValue = new ValueUint(76L);
Value[] byteValues = new Value[]{
    new ValueByte((byte)1),
    new ValueByte((byte)2),
    new ValueByte((byte)3),
};
Value byteArrayValue = new ValueArrayDynamic(byteValues, new TypeByte());

Value value = new ValueTuple(new Value[]{ intValue, byteArrayValue });

byte[] encoded = value.encode();

Comparatively, if there were no Value classes and the Type class had methods public byte[] encode(Object value) and public Object decode(byte[]), this is what it could look like:

Type type = Type.fromString("(uint64,byte[])");

long intValue = 76;
byte[] byteValues = new byte[]{ 1, 2, 3 };

List<Object> tuple = List.of(intValue, byteValues);

type.encode(tuple);

The second seems significantly shorter, easier to write, and safer, since the type string would validate the Java values being encoded against the schema. Apologies for brining this up rather late, but what do you think?

(I also left some smaller comments)

[ahangsu]

Removing Value class is fine, I agree with this decision, and it should be practical.
I had some further thinking: it seems golang supports interface{} type, which is similar in Object in Java. In this way, we can pass a list of interface type values into a encoding method, then infer the go-types and do the abi-type checking.

It seems to me that a rough structure of code change is shaped. Do we need to further reformat the code in go-algorand?

[jasonpaulos]

Great! I also agree it would be beneficial to do a similar thing for the Go SDK and take advantage of interface{}.

But there is one issue that will make the Go implementation more annoying than Java or any of the other languages. That is that you cannot view a slice of concrete types as a "general" slice, e.g. []Type cannot be viewed as []interface{}.

For example, in Java we can use the wildcard type ? during the encoding to handle both List<Integer> and List<Object> effectively, like so (List<Object> is needed to support tuples, where each element may be a different type):

Object objectToEncode = ...;
if (objectToEncode instanceof List<?>) {
    List<?> asList = (List<?>) objectToEncode;
    for (Object item : asList) {
        // encode each child
    }
}

But in Go, if we want to support a tuple encoding function that can accept any slice type, we would need to do:

var input interface{} = ...

switch value := input.(type) {
case []interface{}:
	// handle a slice of interface{} to support tuples containing different types
case []uint8:
	// handle a uint8 array to support tuples/arrays of all uint8s
case []uint16:
	// ... repeat for every supported type
}

I still think it's worth it because the resulting API will be much easier to use, but it might require some long switch statements 😅

[jasonpaulos]

It looks a lot cleaner without the Value classes!

Most of my comments are about Java type conversions. Could you also add some simple unit tests to check that these types are properly accepted? E.g. List<Integer>, Integer[], and int[] should all be valid input types to Type.fromString("uint64[]").encode

[jasonpaulos]

Looking good, just one final comment

Additionally, could you add docstrings for isDynamic, byteLen, encode, and decode on the Type class?