- fromBytes allows to pass any seed you want
- constructor takes PeerId (previously was empty and maybe private)
- toEd25519PrivateKey to complete the lifecycle.
* FluenceClient renamed to FluencePeer.
* Using Aqua compiler is now the recommended way for all interaction with the network, including services registration and sending requests
* Old API (sendParticle etc) has been removed
* Opaque seed format replaced with 32 byte ed25519 private key. KeyPair introduced
* Documentation update
Complete rethinking and refactoring of the codebase.
The codebase basically consists these 5 moving parts now:
1. Fluence client (and the Particle processor which might be merged with the client) - This part is responsible for initiating Request flows, managing existing requests flows (it keeps the queue of received particles), pulling right strings on request flows to update their state etc
2. Fluence connection - This part is responsible for connecting to network, sending\receiving particles
3. RequestFlow - This is where the state of particle execution process is kept. It is basically a state storage with some control levers to update the state. Each request flow contains some particle lifecycle methods and the AquaCallHandler where all callback logic is kept
4. RequestFlowBuilder - This is where requests are prepared by the user (the developer of the client application) before they are ready to be sent into the network.
5. AquaCallHandler - This is how interpreter callbacks are handled. It is very similar to express.js app and is made of middlewares. Aqua handler is the unified api for both callbacks for our Request flows and non-ours (i.e services that are expected to be called be other peers). See `AquaHandler.ts` for details
Big codebase refactoring.
* Multiple clients are allowed on the same browser instance
* Particle queue processing is split from particle handling logic
* Public AIP is completely rethought
* Updated project file structure. Clean exports for public api methods
* Additional unit tests
