Chore e2e tests for full transaction lifecycle after introducing sci callback

[kbeker]

Resolve #744
Resolve #970

I haven't find any better name for SCIBaseTest so if you guys will have any idea for better name just tell me :)

[rwrzesien]

Generally ok, but a lot of minor stuff so I am marking as request changes to follow up on this one.

[Jakub89]

I spoke through email with Igor from Golem recently, and he said that there is a way to make those payment transaction x6 faster. This is what he wrote:

...
powyzsze kroki realizuje klasa GNTConverter, która znajduje się w SCI, więc może będzie łatwiej z niej skorzystać.
API GNTConvertera jest następujące:
0. Musisz mieć GNT na koncie, więc wykonujesz to po request_gnt_from_faucet
1. Wołasz convert z wartością, którą chcesz przekonwertować
2. Wołasz is_converting w pętli (co 15 sekund na przykład) aż zwróci False, wtedy konwersja będzie zakończona. Całość może potrwać ~5min dla świeżego konta i ~3min dla używanego.

Golem nie korzysta z tej klasy właśnie przez aktywne oczekiwanie i przez to, że implementacja jest lekko nieoptymalna i można uzyskać krótszy czas oczekiwania, ale zostawiłem ją dla wygody do testów.
I dla zwiększenia szybkości testów na testnecie można sobie nadpisać stałą REQUIRED_CONFS na 1, wtedy wszystkie transakcje będą potwierdzone 6x szybciej, więc oczekiwania będzie dużo mniejszy :)

[cameel]

@Jakub89

I spoke through email with Igor from Golem recently, and he said that there is a way to make those payment transaction x6 faster. This is what he wrote:

...
powyzsze kroki realizuje klasa GNTConverter, która znajduje się w SCI, więc może będzie łatwiej z niej skorzystać.
API GNTConvertera jest następujące:
0. Musisz mieć GNT na koncie, więc wykonujesz to po request_gnt_from_faucet
1. Wołasz convert z wartością, którą chcesz przekonwertować
2. Wołasz is_converting w pętli (co 15 sekund na przykład) aż zwróci False, wtedy konwersja będzie zakończona. Całość może potrwać ~5min dla świeżego konta i ~3min dla używanego.

Golem nie korzysta z tej klasy właśnie przez aktywne oczekiwanie i przez to, że implementacja jest lekko nieoptymalna i można uzyskać krótszy czas oczekiwania, ale zostawiłem ją dla wygody do testów.
I dla zwiększenia szybkości testów na testnecie można sobie nadpisać stałą REQUIRED_CONFS na 1, wtedy wszystkie transakcje będą potwierdzone 6x szybciej, więc oczekiwania będzie dużo mniejszy :)

Sounds like a good idea (well, as long as orphaned blocks are not common on the testnet; I'll take Igor's word for that). This would require setting SCIImplementation.REQUIRED_CONFS when we create an instance of the class. This is a class attribute (not instance attribute) so changes to this attribute are global. That should not be a problem as long as we set it before first use and no other part of the code changes it. But please make sure that SCI spawns its thread after we change the value. Otherwise it might be using the wrong one.

We could add a setting like OVERRIDE_REQUIRED_BLOCK_CONFIRMATIONS. By default set to None. If it's anything else than None, use its value to initialize REQUIRED_CONFS. In development.py and testing.py could be set to 1.

@dybi If you think it's a good idea, we could create an issue for this.

[cameel]

If the test cases in this pull request are based on examples from the #996 blueprint, please note that the expected results might change a little. You may need to update the pull request or create another after the blueprint is updated.

[kbeker]

@cameel

If the test cases in this pull request are based on examples from the #996 blueprint, please note that the expected results might change a little. You may need to update the pull request or create another after the blueprint is updated.

This PR doesn't change logic at all. I think any changes to tests logic should be done in different PR.