Add support for optimization mode

[tarunbhm]

closes #71

• unit test cases

[tarunbhm]

Seems like there is race condition in the value being computed because the same value is updated by all the workers. I think ideally we should have an instance of value for every worked index and reset it on WorkerDestroyed event. One more thing which is not clear to me is how do we decide if we have reached the maximum possible value for the optimization test case? I mean our fuzzer may stop before reaching the max value because of test limit or time limit.

Looking through the code I also see that that testCase.workerStates is reused between workers on same index because it is not reset when a worker is destroyed. It may not be a problem because all the contracts are deployed again when a new worker is created and this triggers testCase.onWorkerDeployedContractAdded method which updates the testCase.workerStates with new values. It could become a problem if in future we make changes in initial deployment procedure based on worker index or some other parameter. cc @anishnaik @Jaime-Iglesias @Xenomega

Update: I have fixed it with the mutex for now

[anishnaik]

@tarunbhm do you want to go ahead and update this PR with the latest master branch? Happy to get this merged ASAP. Apologies for the delay.

[CLAassistant]

All committers have signed the CLA.

[ggrieco-tob]

I'm taking care of this. It seems that it should be ready for another review. I added some code to actually show the sequence of transactions that maximized certain function (otherwise, it was not useful, since these tests should never fail)

[anishnaik]

Hey @tarunbhm + @ggrieco-tob so I did a review of this PR and I added the capability to shrink a call sequence that optimized the test case's value. This was something that was missing from the PR. However, during this development I realized that we will have to put this PR on hold for now b/c of the inefficiency of the call sequence shrinking. The reason it is inefficient is because every time the value is maximized, we send a shrink request. however, after the shrinking is done, we do not mark the test case as failed b/c the next call or call sequence could in fact maximize the value even more. Then, another computationally intensive shrink request can be triggered on the next call in the call sequence. Thus, optimization mode doesn't really have a "stop" - it keeps going as long as the fuzzer keeps going. Since we cannot do a one-time shrink request at the moment, this PR will have to be on hold.

Ideally, we could call FuzzerWorker.shrinkCallSequence directly but that does not work given the way medusa is structured and how the fuzzing loop is set up. We will have to wait until we integrate a higher-level testing API so that we can support arbitrary shrinking requests. This would allow us to only shrink optimization call sequences one time instead of a gajillion times.