* Catch web3 tx not found exception (API changed in versions > 5.0.0)
* Fix missing one_minus_ones elements
* Refresh the cache of preprocessed elements after the writing to file
  step is done. There was a line `pp_elements.init_mixins()` which looks
  like it was expected to do something similar but the method
  (`init_mixins()`) does not exist. Perhaps it can be implemented in the
  future.

Related to initc3#425

For the time being because it is sometimes difficult to understand why
the patch coverage is too low and this prevents moving forward with
merging a pull request which does not affect the overall coverage of the
project.

* Add documentation for asynchromix app.
* Remove extra whitespace in asynchromix contract

This was derived from apps/asynchromix/asynchromix.[py,sol].

The "mixing" part of the original asynchromix app was
removed to make it into a simple app in which a client sends
a mask message and the MPC network unmasks it.

Perhaps there is no need for an ethereum-based coordinator for such a
simple case but the idea is to provide a basis for more complex
applications such as message mixing and intershard secure
communications.

Far from elegant and very rudimentary first version that can
for sure benefit from many improvements.

Some of the current limitations are:

1. The client sends messages to a gateway shard, meanwhile the
   other shard only receives masked messages from this gateway shard.
2. The complete message transmission, from client to gateway shard to
   "receiving" shard all happens within an epoch.
3. The generation of preprocessing elements for the intershard transfers
   is "fake", as it is done at start up time as though a trusted dealer would
   distribute field elements (masks shares) to each server.
4. The contract does not control access to the queue of intershard
   messages thus allowing "un-authorized" reads.

From the above limitations, things to improve are roughly:

1. The message transmission flow can go from client to any shard, and the
   first receiving shard will forward it to the other.
2. Not sure, but it seems to me that the "complete" message transmission
   (client -> shard 1 -> shard 2) does not need to be all happening within
   one epoch. That is, the shard that produces messages and the shard that
   consumes messages do not need to operate at the same rate, since the
   producer queues up messages and the consumer consumes the messages from
   the queue; they can be operating at different speeds.
3. Implement randousha-based generate_intershard_masks() function.
4. Tidy up the access control using a SecretCellArray data structure in
   the contract.

The goal is to organize the code such that the pieces belonging to
different "actors" are ideally fully isolated. That is, the client code
is just client code, the MPC server/network code is just MPC server code,
the contract deployment code is just contract deployment code, etc. With
this separation it should be possible to run each component
independently of each other, such as in different processes, or different
containers.

Now running two containers:

1. ganache (local test ethereum)
2. client & MPC servers

Next: Run the client and MPC servers in separate containers, that is:

1. ganache (local test ethereum)
2. client
3. MPC servers

Could also potentially run the deployment of the contract separately.

* contract is deployed in a separate service and address is written to
  a file that can be read by all parties
* servers are instantiated with a contract context (address, name, source
  code)
* Client reads the contract address from pubic data, and creates web3
  Contract object to interact with the on-chain contract.
* MPC servers serve a GET /inputmasks/{id} endpoint
* Client queries servers for input mask shares
* Makefile can be used to launch example into tmux panes for each
  service (ethereum blockchain, setup phase (contract deployment), MPC
  network, client)

next:
* config for public data including ethereum addresses of client and
  servers
* authorization check for clients when they query a share
* MPC server communication over network sockets
* preprocessing service
* cleanup

note: some of the above next steps may be done at at later stage

* Add client.toml config file and .from_config() class method to create
  a Client class instance from configuration dictionary.

next:
* Setup Phase - create a toml file with public values, such as contract
  address, name, file location.

The setup phase for now is responsible to deploy the contract and to
provide the contract address to the MPC servers and clients.

Additionaly, the contract deployer, the MPC servers and clients, need
an eth address and for now a "dummy" eth address is assigned to each
participant. The addresses can be added to the common config file.

next:
* make sure all common data is in the config file
* update client config with just client config data
* use config for mpc network

The goal is to provide a somewhat generic Client class that can be used
as a base for specific clients.