Implementation of deposit, requestExit and withdrawFunds functions

[philippecamacho]

Part of #737.

To test:

> just sol-test

Implements the three functions deposit, requestExit and withdrawFunds. Note that the queue logic for registration and exit will be addressed in another PR.

[alxiong]

I think pending queue logic is little tricky when we support deposit.
for register and exit, we could set their registerEpoch and exitEpoch to the nextRegister/ExitEpoch() based on the queuing logic.
However, it's currently underspecified how this queue works, or who would clear the queue and when.
and when there's deposit, the current struct Node is not sufficient to capture "this node currently is active and has 10 token, but he has another 5 pending token to be active in epoch X down the line" info.
^^ we need to discuss this.

note: I haven't review the tests yet, since there are a few things to settle on contract logic first.

[philippecamacho]

However, it's currently underspecified how this queue works, or who would clear the queue and when

The way the queue is specified does not require any cleanup process: the queue just tracks two numbers that are updated when next{Register/Exit}Epoch is called.

struct Node is not sufficient to capture "this node currently is active and has 10 token, but he has another 5 pending token to be active in epoch X down the line

Yes, I agree. The current specification allows for balances to change within an epoch and that feels wrong. Let us discuss.

cc @jbearer

[philippecamacho]

I think pending queue logic is little tricky when we support deposit.

@alxiong The queue logic (for both Registration and Exit) is implemented in #803.

[philippecamacho]

However, it's currently underspecified how this queue works, or who would clear the queue and when

The way the queue is specified does not require any cleanup process: the queue just tracks two numbers that are updated when next{Register/Exit}Epoch is called.

struct Node is not sufficient to capture "this node currently is active and has 10 token, but he has another 5 pending token to be active in epoch X down the line

Yes, I agree. The current specification allows for balances to change within an epoch and that feels wrong. Let us discuss.

cc @jbearer

Based on the zulip conversation, I would add a test to ensure a user can deposit several times inside an epoch when the node is active.