The mock runtime addVerifiedClient function is now overloaded to support an optional expectedAllowance arg to be used in the cases where VerifiedClients will now have more than what was initially allotted. This makes the verification of an expectedAllownace a concern on the caller rather than letting the function reflect on its internal before/after state to verify correctness. I'd personally prefer the latter to keep the call simple, but there were errors when I attempted to access the runtime map for the "before" state of the Client's DataCap allowance. (An example of that is at https://gist.github.com/placer14/f2134a4064373607da44b48b4f338d69.)
This change will mix all Verifier's allowances together for each Client address. If there were ever a need to know how DataCap is used on a per-Verifier basis, we would be eliminating that option here.
The unit test which protects that a VerifiedClient can be referred to be its ID and non-ID addr is also protecting its ability to be topped-up. If it's preferred that these behaviors are protected by separate tests, I can, but felt the redundancy was unnecessary and left them combined.
This change does not limit the DataCap upper bound and expects that DataCap boundaries are already protected where necessary.
Implements FIP-0012 and fixes #1325.
Thoughts on these changes:
addVerifiedClientfunction is now overloaded to support an optionalexpectedAllowancearg to be used in the cases where VerifiedClients will now have more than what was initially allotted. This makes the verification of anexpectedAllownacea concern on the caller rather than letting the function reflect on its internal before/after state to verify correctness. I'd personally prefer the latter to keep the call simple, but there were errors when I attempted to access the runtime map for the "before" state of the Client's DataCap allowance. (An example of that is at https://gist.github.com/placer14/f2134a4064373607da44b48b4f338d69.)