Remove old vote transaction and exception handling - Closes #5074

[shuse2]

What was the problem?

This PR resolves #5074

How was it solved?

• Remove old vote transaction and handling of it
• Remove exception handling

How was it tested?

• All test passes
• Application runs as expected

[pablitovicente]

Can we make the transaction numbers sequential?

this PR leaves:

8: TransferTransaction,	
10: DelegateTransaction,
12: MultisignatureTransaction,
13: VoteTransaction,
14: UnlockTransaction,

better to leave it as:

9: TransferTransaction,	
10: DelegateTransaction,
11: VoteTransaction,
12: MultisignatureTransaction,
13: UnlockTransaction,

(It seems when we deleted the 2nd signature we were already jumping one number but I think it would be much nicer if numbers are sequential)

The rest looks good. Thoughts?

[shuse2]

if we proceed with https://research.lisk.io/t/introduce-numbering-scheme-for-transaction-types/220, it would be completely different numbering, too
I would wait for the idea to go into the LIP repo to change it
Also, i just realized, but maybe it's bit better if vote and unlock are next to each other coz they are related

[pablitovicente]

if we proceed with https://research.lisk.io/t/introduce-numbering-scheme-for-transaction-types/220, it would be completely different numbering, too
I would wait for the idea to go into the LIP repo to change it
Also, i just realized, but maybe it's bit better if vote and unlock are next to each other coz they are related

OK. Then maybe create the issue for the renumbering so it's in the backlog?

[ManuGowda]

LGTM

[ManuGowda]

since we no longer have exceptions.. why don't we change function to??

export const validateTransactions = (transactions: ReadonlyArray<BaseTransaction>): ReadonlyArray<TransactionResponse> => 

[shuse2]

I think this was originally to make all the transaction interface the same.
Also, composeTransactions relies on this.
We should refactor it but prefer to do it in the separate issue

[ManuGowda]

and the composeTransactions was designed to address this exceptions if i understand correctly? I don't have the context though. but if it doesn't make sense now, its better to clean it up now. otherwise you can ignore this comment 👍

[shuse2]

composeTransactions was just a way to handle multiple cases for transaction validation and keeping the context while injecting to the transaction pool.
Ill create an issue to address this

[shuse2]

Created: #5088