Temporary Increasing TCS amount to 3

[elichai]

Introduction

The way threads inside the enclave works is by multiple threads trying the access the enclave from the untrusted.

The amount of threads that can do that in parallel is decided by the value of TCSNum in the xml As written here: https://download.01.org/intel-sgx/linux-2.5/docs/Intel_SGX_Developer_Reference_Linux_2.5_Open_Source.pdf page 65.

We don't know enough what's the security implications of launching multiple threads in the enclave, because they share the same memory.

The problem

Right now there are 2 problems:

1. Both get_state_keys and watch_blocks try to access the enclave while running in separate threads.

2. The current JSON-RPC server initiates 2 threads even though it should only initiate 1. (Somehow the server always spawn at least 2 threads. paritytech/jsonrpc#425)

Temporary Solution

This PR will temporarly increase the number of allowed threads to 3 to answer the 3 threads I stated above.
This solution cannot go into production without seriously understanding and evaluating the risks.

Future Solution
I think the right solution for production is as follow:

Only 1 entity would control the enclave itself. the eid won’t be passed around and only that entity will make ecalls.

we will try to minimize the amount of threads to the minimum required (it seems that 2 unless we can try and make everything async which isn’t too easy in rust)

The enclave object itself will be guarded by a Mutex so that no 2 threads can make an ecall at the same time. that way they won’t be able to interfere with each other.

CC @fredfortier @lacabra @moriaab @AvishaiW #137

[elichai]

The build is failing due to unrelated issues. I'll fix them in a new PR