feat(api-server): configurable validation process

[Abhishek2700]

Q1.) Making Validation process configurable
I am running the simple-asset-transfer example given in the repo.

I want to modify some functionality in the validation step that is going on currently. I want to loop through the available validator nodes , send a heartbeat request to confirm that they are alive and then ask them to validate the asset transfer/locking, sign a message and then move onto the next validator.

What is happening right now is that there is an election which determines the leader and follower validator nodes. validation request is passed onto the leader which then asks the follower to sign it and then returns all the signatures from validator nodes as proof that the transaction has been validated.

I came to know that etcd services is being used for the election . So i tried

(i) Removing the dependency of etcd services for each validator in the yml file.
(ii) Remove the etcd services completely from the yml file.
Then i rebuild the image , restarted the validator nodes and even peer nodes. But either the validator nodes not start at all or they do start and the election starts but it cannot resume from there as the etcd services are not working.

SOULTION I WOULD LIKE

I want to make the election process optional/configurable so that i can make the validation process sequential and to be able to do heartbeat requests , validation and signing requests any validator node just by using its address. I don't want the first validation request to be passed onto the leader who then asks for the validation from all the follower nodes , collects all the signature and returns them.

Acceptance criteria

1. There's passing end to end test that shows how different Cactus node's API servers' can be targeted for requests for validation.

[NoahMarconi]

The elaborate on the use case, some multi-signature schemes require sequential signing as the previous signature is part of the payload that needs to be signed but the next signer.

[petermetz]

The elaborate on the use case, some multi-signature schemes require sequential signing as the previous signature is part of the payload that needs to be signed but the next signer.

@NoahMarconi Good to know, thank you for clarifying!
Ending the leader elections is still something we should do, but based on this I'm also considering that maybe specifying the order of signatures could be part of the signing request so that "it just works" instead of people having to write a lot of boilerplate around their signature requests.

[NoahMarconi]

That kind of configuration would be great.

What you suggest (configuring order) coupled with configuring the data payload signed (e.g. a network specific transaction) would help support a variety of networks.

[petermetz]

Note to self: Need #136 resolved prior to implementing this.

[petermetz]

This depends on the routing interface being operational first, assigned milestone according to that constraint.