TRN-382 Prevent EthCallNotarization Resubmission

[JCSanPedro]

This PR is to specifically address the audit issue FRN-37.

The audit ticket describes a vulnerability where EthCallNotarizations can be resubmitted, potentially allowing a single notary to affect the outcome of an eth call notarization. Within the implementation of submit_notarization, the notarization is persisted in storage, but there is additional validation to ensure that a submission has not already been submitted. It has also been noted that for EventNotarizations, there is sufficient validation to prevent resubmission.

To remedy this, we follow the same logic as EventNotarizations does, where within the validate_unsigned implementation, we check the storage to ensure the notarization has not been resubmitted.

NOTE

This PR is effectively non-functional. Notarization submissions do not actually occur in production, as submit_notarization is only triggered in the cases:

1. Where an event notarization for an eth tx that has been challenged, which will never happen though because we have blocked the challenge functionality. Check out the call filter here, which prevents these calls from executing
2. For call notarizations which isn't hooked as the eth-state-oracle was not brought along when this repo transitioned from Cennznet -> TRN

Furthermore, the UnsignedValidator was not correctly implemented for the ethy-pallet as it was missing the #[pallet::validate_unsigned] proc macro. This means that unsigned extrinsics being sent to the ethy-pallet were never correctly validated in the first place.

The only value of merging this PR is to:

1. Say that we addressed the audit problem (ticking boxes essentially)
2. Ensure that we have addressed this problem once we do eventually reintroduce decentralized notarizatios and/or the eth-state-oracle

A more long term solution would involve refactoring the ethy-pallet in it's entirety (started here).

[JasonTulp]

lgtm, thanks for going through the weeds to get to this conclusion. Appreciate your time