3.0.0: Improve object encoding and decoding

[jasonpaulos]

• Upgrade to the newly released algorand-msgpack library
• Remove the from_obj_for_encoding and get_obj_for_encoding methods. In their place, introduce the following:
  • An Encodable interface with a toEncodingData method, and a static fromEncodingData method. "Encoding data" is an intermediate representation of the object in a JS Map, similar to the output of our Python SDK's dictify method.
  • The Encodable interface also has a getEncodingSchema method and a static encodingSchema property, which return instances of the new Schema base class.
  • The Schema class is how "encoding data" gets transformed for encoding/decoding to/from JSON and msgpack. For example, AddressSchema converts an Address class to its 32-byte public key for encoding in msgpack, and for JSON it converts the address to its base32 string form. Specifically these translations happen in the prepareMsgpack/fromPreparedMsgpack and prepareJSON/fromPreparedJSON methods.
• Replace EncodedSignedTransaction interface with SignedTransaction class

While the introduction of Schema adds some complexity, it also has these benefits:

• Consolidating encoding decisions which otherwise must be spread across every class's encoding/decoding functions
• Reducing mistakes which can be made in each implementing class. No longer do they need to worry about omitting empty values or correctly dealing with base64 encoding for JSON. The toEncodingData and fromEncodingData can be more straightforward translations now.
• Real, configurable support for omitting empty values. The NamedMapSchema class determines if empty values should be omitted and seamlessly restores omitted values when decoding.
  • Right now each map field has boolean properties omitEmpty and required which control different functionality. omitEmpty, if true, omits default values during encoding, while required is used for values which may or may not be present on the object.
• Opens up the possibility of using non-string keys, which are necessary to support blocks and stateproof transactions (to be addressed in a later PR)

This relies on generator changes as well from https://github.com/algorand/generator/pull/73

[emg110]

Hey @jasonpaulos, some of these look not to be backward compatible and to some extent breaking changes. Are they?

[jasonpaulos]

@emg110 this is still a work in progress, but yes, there are breaking change here. That's why this is going into the v3 branch