Handle *_DELEGATE Transaction Service events

[iamacook]

Summary

The Transaction Service now emits new *_DELEGATE events for creating, updating and deleting delegates:

• NEW_DELEGATE
• UPDATED_DELEGATE
• DELETED_DELEGATE

This adds the relevant validation and handling of the aforementioned, clearing the delegates cache accordingly.

Changes

• Add schemas, inferred entities and relevant builders
• Add method to clear delegates, called by each event

[iamacook]

I'm marking this as a draft for now as there is no chain identifier for each event. I've discussed this with @falvaradorodriguez, and he will add them soon. A chainId property is preemptively added accordingly.

This has now been resolved.

[hectorgomezv]

Could you elaborate on the case the event is not directly related to a Safe address? I'm not super sure of the this, but does this happen if the delegate is linked to a delegator, but not to a specific Safe? Is it therefore is linked to all the Safes the delegator owns? Maybe we should include a comment explaining the case, wdyt?

[iamacook]

I'm not entirely sure why or how this can happening but the event can potentially have no address according to the Transaction Service.

[falvaradorodriguez]

Just to comment. Right now, it is possible to create a delegate for a delegator without a specific safe. In that case, the delegate user would be valid for all safes of the delegator user. If a specific safe is specified, it would only be valid for operations on that safe.

[hectorgomezv]

Thanks guys! Then if I understood correctly, if the Safe address included in the event is null we would need to clear the cache for all the Safe addresses the delegator owns. Do you think this is correct? @iamacook @falvaradorodriguez? 🙂