Better support for async/await threading model

[badrishc]

The FASTER model is based on a set of threads, each of which can start a session with FASTER, perform a sequence of operations, and later stop the session. Operations consist of bursts of activity, with periodic invocations of a Refresh() call to FASTER in between. It would not be okay for a thread/session to go to sleep (i.e., stop calling Refresh) without stopping its session. Sessions and threads are tightly integrated in this model.

However, this tight coupling of threads and sessions in FASTER is not ideal for an async/await API using the C# thread pool. This PR aims to investigate and prototype alternatives to this approach, and implement the best one. There is next to no code right now, this PR for now serves as a place to discuss options and alternatives.

See #130 for some more discussion and a very early work-in-progress PR.

[marius-klimantavicius]

Does FKV guarantee that changes (Upsert) in one session is "immediately" visible in another sessions? If not the ThreadPool would not work:

await UpsertAsync(key, value);
await ReadAsync(key);

Both awaits could be scheduled to different threads (thus sessions) and I'd expect ReadAsync to return value that was set by UpsertAsync (provided noone else modified it in the mean time).

[badrishc]

On a single machine, yes. FASTER depends on CPU cache coherency to ensure this. If your example, the read would be guaranteed to see the result of the upsert, even if issued from a different thread.