Extend testing configuration to run integration tests on the CI server

[rrtoledo]

This issue is specific to tests on the python client and contracts, located in pyClient/test.

So far, the "make" commands do not execute most of the tests [1], and it is unclear whether they need to be updated as the code evolved considerably for the past month. It is worth doing a review of the code and list new potential tests (needed, desirable...).

This issue is about updating, and creating contract and client tests as well as facilitating their use. Ideally, Travis would run them after each push.

I propose to have, for instance, make commands such as:

• make test_contracts, to test all contracts
• make test_client, to test (at least the essentials functionalities of) the client
• make test_all, to run all tests (unit, contract, client tests). It is worth considering merging this command with make check to also test syntax.

[1] I have created a command in the packing branch to test a couple of contracts but they need truffle to be running.

[rrtoledo]

• Is it possible to run ganache on travis? How should we do that (process wrappers, tmux, docker compose ...)?
• Testing contracts
  • create zeth-contracts/tests for test contracts
  • move python code to zeth-contracts dir?
  • reuse pyClient by importing relevant modules
  • limit the use of Web3 and try to use low level functions (as the library is not very stable)
• look into reusing the keys and proofs from prover_server for further tests
• look at packages for standard testing (ganache test was used before, look at pytest and so on)

[AntoineRondelet]

Over the past few months, the CI and testing scripts have been refactored quite a bit.

Furthermore, #313 has just been closed (as well as #258), meaning that we now have a working pipeline for consistently publishing new docker images to the Hub.
This, coupled with the various testing scripts (https://github.com/clearmatics/zeth/tree/master/scripts), paves the way for what comes next: using docker-compose-type tools to run the full integration tests on the CI server.
The goal here will be to write a docker-compose.yml file to spin up:

1. a prover_server (image: clearmatics/zeth-prover),
2. a client (image clearmatics/zeth-client), and
3. a ganache instance (preferably the image built from our fork - that contains custom pre-compiled contracts for arithmetic over BLS12: Fix docker configuration ganache-cli#1)

to run the integration tests on the CI (wallet > prover_server > blockchain/ganache/contracts).

Likewise, a similar configuration will be used to run the mpc integration tests (e.g. 1 coordinator service and 2 contributor services generating an SRS for the simple_gadget).

[AntoineRondelet]

cc @eastata

[dtebbs]

This could be worth investigating this for slow dependencies on the ci:
https://docs.github.com/en/free-pro-team@latest/actions/guides/caching-dependencies-to-speed-up-workflows

Looks pretty flexible and should be uniform over mac and linux.

[AntoineRondelet]

3\. a ganache instance (preferably the image built from our fork - that contains custom pre-compiled contracts for arithmetic over BLS12: [clearmatics/ganache-cli#1](https://github.com/clearmatics/ganache-cli/pull/1))

The PR linked here (i.e. clearmatics/ganache-cli#1) has finally been fixed and merged. As such, it is now possible to launch our custom ganache-cli instance in a docker container, paving the way for integration tests (in linux) via docker-compose.

[AntoineRondelet]

This ticket is addressed in #326

[AntoineRondelet]

Closing this ticket now that #326 is merged.