Implement Gnosis withdrawals pull

[dapplion]

Current master (via #25) implements push withdrawals. We originally decided to implement this strategy because:

• Requires the least amount of actions from stakers, which get the withdraw tokens credited in their address by block processing
• This behavior follows the UX in Ethereum, which is what stakers may expect here too

However @filoozom noted that since the ERC20 transfer happens as part of receipt-less system transaction, the Transfer logs are not accessible anywhere. This breaks downstream tooling and will cause token balances to be incorrectly reported. Otherwise tooling is forced to incorporate custom logic to handle this differences, raising the cost of the feature.

Due to this in the last core devs call consensus is formed that the incompatibility in tooling + the extra complexity does not justify going for the push strategy.

This PR implements a pull strategy, which requires a final claim step to credit the withdrawn tokens to stakers. The claim happens in a regular transaction after the withdrawal block, so the Transfer receipts are available. Also, the insolvency case does not need to be handled explicitly, which significantly reduces the complexity of the contract to basically this two functions:

deposit-contract/contracts/SBCDepositContract.sol

Lines 249 to 265 in 2e2eea9

	function executeSystemWithdrawals(
	uint256 _maxNumberOfFailedWithdrawalsToProcess,
	uint64[] calldata _amounts,
	address[] calldata _addresses
	) external {
	require(
	_msgSender() == SYSTEM_WITHDRAWAL_EXECUTOR || _msgSender() == _admin(),
	"This function should be called only by SYSTEM_WITHDRAWAL_EXECUTOR or _admin()"
	);
	assert(_amounts.length == _addresses.length);
	for (uint256 i = 0; i < _amounts.length; ++i) {
	// Divide stake amount by 32 (1 GNO for validating instead of the 32 ETH expected)
	uint256 amount = (uint256(_amounts[i]) * 1 gwei) / 32;
	withdrawableAmount[_addresses[i]] += amount;
	}
	}

deposit-contract/contracts/SBCDepositContract.sol

Lines 271 to 277 in 2e2eea9

	function claimWithdrawal(address _address) external {
	uint256 amount = withdrawableAmount[_address];
	if (amount > 0) {
	withdrawableAmount[_address] = 0;
	stake_token.safeTransfer(_address, amount);
	}
	}

Note that anyone can claim for any address. I expect Gnosis devops or other interested parties (staking services) to sponsor and auto-claim on behalf of stakers such that the perceived UX for the staker is the same as with the push approach

[Barichek]

Seems good. I would just suggest to remove legacy comments above executeSystemWithdrawals function and remove uint256 _maxNumberOfFailedWithdrawalsToProcess from list of input parameters of it.

[dapplion]

Seems good. I would just suggest to remove legacy comments above executeSystemWithdrawals function and remove uint256 _maxNumberOfFailedWithdrawalsToProcess from list of input parameters of it.

@Barichek we cannot change the function signature of executeSystemWithdrawals or the execution clients will break. What name would you suggest to assign the variable?