issue42/64 transaction batching

[ranadewall]

Resolves #42.

I took out the memo field for now because we aren't using it in this repo and it requires special attention on batching when it is populated - txns that need it cannot be batched if the memo field is not unique because it is applied to every txn in the batch.

TODO:

• [x] decouple the burn from redemption so that we can batch redemptions
• [x] all the tests need to be fixed/added

Includes some changes for https://github.com/provenance-io/digital-currency-consortium/issues/64 as well given the need to decouple bank deposit requests from the redeem/burn cycle as part of the batch @leeduan

[scirner22]

One thing to check for would be how batching effects the response stream. I had to add that splitAttributes function to the transaction filtering events, but it might be needed across the board with an introduction like this.

[leeduan]

One thing to check for would be how batching effects the response stream. I had to add that splitAttributes function to the transaction filtering events, but it might be needed across the board with an introduction like this.

still need to check this

[leeduan]

One thing to check for would be how batching effects the response stream. I had to add that splitAttributes function to the transaction filtering events, but it might be needed across the board with an introduction like this.

~okay so i think we're okay here because it only applies to parsing provenance.marker.v1.EventMarkerTransfer - everywhere else we parse transfers we're parsing the wasm events which come in separately~

~it does kind of open up question of why we would parse EventMarkerTransfer vs just wasm but I guess the wasm events don't count every EventMarkerTransfer as built~

batching provides a different event per wasm message even though same tx hash - so I think we're fine for these events specifically