Split TEE release into worker and enclave

[Kailai-Wang]

Context

This PR:

• split the TEE release into two parts: worker and enclave
• reworked the release type
• reworded the release building script, I think enclave.signed.so and litentry-worker are the only things to release (= made public)
• applied proper version for worker and enclave:
  • worker starts from 0.0.1
  • enclave starts from 100

We should bump the enclave runtime version for any change that results in a different MRENCLAVE, even if it's not a direct sgx-pallet/runtime change.

TODO:

• maybe to have a GHA to detect mismatch of enclave version and MRENCLAVE (e.g. the MRENCLAVE changes but the version is not bumped) in case we forget it
• SGX_SIGN_PASSFILE is ignored for now, we need to figure out how/if we should use it => an issue will follow

A trial run that builds all 4 artefacts:

• parachain client
• parachain runtime
• TEE worker
• TEE enclave

https://github.com/litentry/litentry-parachain/releases/tag/untagged-e92681d128065981fdb1

[linear]

P-193 Split enclave release into worker and runtime

So far the enclave is released "as a whole" which has a unified version.

Similar to parachain, we should divide it into two parts: the worker (non-enclave) part and runtime (enclave logic) part. It's possible that one of these needs an update while the other is kept unchanged, so we need to handle them separately.

So instead of current release item list (see an example here), which is:

• Client
• Runtime
• Enclave

I suggest:

• parachain-client
• parachain-runtime
• tee-worker
• tee-enclave

Ideally, the versions of tee-worker and tee-enclave will match each other, suggestion:

• tee-worker starts from 0.0.1
• tee-enclave (runtime) starts from 100

We follow a similar naming mechanism to parachain, but reserve the last two digits for enclave update as it's supposed to be much more frequent than the worker update.

Suggested additional information in release log:

• tee-worker → rustc version
• tee-worker → MRENCLAVE

Each time we change the enclave logic (which should result in a different MRENCLAVE too), we need to bump the enclave runtime version. We might need to have a GHA to double-check it in case we forget it - like you have a different MRENCLAVE from the previous release but the version number is not bumped.

From the ts-packages' perspective, they should follow the version of parachain-runtime and tee-enclave, and rebuild the package whenever either of them changes.

[felixfaisal]

LGTM

[kziemianek]

I haven't tried it out but it looks fine.