refactor: enclave runs as a stateful service instead instead of single ecalls

[brenzi]

In order to improve

• performance ( now lots of synchronous file-IO)
  • amount of marshalling per function call
• now ugly maximum-sized ecall arguments allocation

We should turn the enclave into a service providing websockets so the worker has a ws API for interaction with enclave

This way,

• file-io (state dump to IPFS) could happen asynchronously
• no need to en-decrypt state for each request
• optional: enclave could instantiate its own api-client to talk to the node directly

[murerfel]

How would we change the API from essentially a C-API (enclave EDL) to a websocket interface? Isn't the EDL the only way in- and out of the enclave? Can we circumvent this somehow?
The idea would then be to run a WS daemon/client inside the enclave that accepts connections?

[brenzi]

I guess we would use a network interface for this, yes. possibly ws (from local) and wss into enclave (from remote)
But I'm not sure if this is really the best option. We have recently worked with atomic pointers for stateful stuff, which seems to do the trick as well for the cases we've seen. @haerdib Opinions?

The problem described in the issue is actually already solved by executing TrustedCalls blockwise. That's done already, so there's not as much file IO anymore as when we files this issue

[haerdib]

If we turn the enclave into a WS interface the biggest issue I see is multithreading. Within the enclave we are not able to spawn threads ( this will be different with SGX2 hopefully) - so a websocket call directly into the enclave will block the entire socket until the task is finished (of course TCP stream is still able to receive messages, but they can not beread until previous task is finished).

Atomic pointers are working very well. Thanks to the rust compiler I have yet to run into any deadlocks or multithreading issue. However, no stress testing was done until now.. lets see how it will work out for polkadex, as they are using multiple caches with atomic pointer and thread sharing.

[haerdib]

We already have a stateful enclave with locks & atomic pointer, so this issue is obsolete now.