refactor teerex EnclaveRegistry for attesteer

[brenzi]

the current data model is incompatible with the attesteer, because

We currently assume that the extrinsic sender is equal to the signing key the enclave user for authentication at its own rpc which is listening on the port specifiedwith the url argument. This makes sense for Integritee SDK based enclaves because it allows the user to discover and authenticate an enclave for a particular use case (identified by MRENCLAVE) purely based on the information in the EnclaveRegistry

In the case of the attesteer, the extrinsic sender is the attesteer (which wouldn't strictly need to be an enclave in its current state because it merely forwards information as a proxy between Marblerun and the integritee network

Moreover, the url and the authentication key are non-trivial in this case, because we have no way to learn the public url automatically and it is up to the enclave builders to specify an authentication key as part of the SGX quote. The url is a minor concern, because this could be self-declared by the operator of the enclave.

But the authentication is key. Otherwise RA is worthless

The standard way of solving this is to add an ECDSA pubkey to the SgxReportData

pallets/teerex/sgx-verify/src/lib.rs

Lines 260 to 265 in be26e6b

	/// Custom data to be defined by the enclave author.
	///
	/// We use this to provide the public key of the enclave that is to be registered on the chain.
	/// Doing this, will prove that the public key is from a legitimate SGX enclave when it is
	/// verified together with the remote attestation.
	report_data: SgxReportData, /* (320) Data provided by the user */

these are 64 bytes which can be used however the enclave author wants to, so we should just parse and register the entire 64 bytes in raw format and leave it to the user to interpret the data.

We may need to expose a new dispatchable for this which expects no url and which can be called by non-enclaves too

But we will need to rethink the entire data model of the registry, because currently we assume that each enclave has an AccountId - which no longer is the case

[brenzi]

in the same go, we may want to include the SgxStatus in the Enclave struct and close #83

[brenzi]

consider this WIP: https://integritee.atlassian.net/wiki/spaces/INTEGRITEE/pages/544866336/teerex+V2

[brenzi]

according to the refactoring spec linked above, solving this issue will be the result of:

1. [teerex] refactor for abstraction of SGX technology choice #185
2. [teerex] unify dispatchables for enclave registration #186
3. [teerex] introduce separate storage for proxied enclaves #188

the other related issues are not strictly necessary for the attesteer to work: #183, #184, #187