gnosis / dex-services / 5579

31%

push

travis-pro

[Fuzzing] Allow to specify max memory size (#1553)

Fixes alerts in dev channel regarding the fuzzing pod using too much memory.

I'm not entirely sure if this is the right approach to go, but it seems the [fuzzing pod](https://dashboard.gnosisdev.com/d/ab4f13a9892a76a4d21ce8c2445bf4ea/kubernetes-pods?orgId=1&from=1606147837298&to=1606158637298&var-datasource=prometheus&var-cluster=&var-namespace=dfusion&var-pod=dev-dfusion-services-fuzzing-9545cdf5b-cmvrr&var-container=All) is using well above its requested memory and almost its limit, despite having as much resources as the price-estimator pod itself (which is running the code that is being fuzzed). 

This PR allows to set a [max rss limit option](https://llvm.org/docs/LibFuzzer.html#options) in the fuzzer which we can then set in the pod to be the requested memory size. This should render cases as failed if the process is requiring more memory to process them. In theory this would then cause the pod to find a lot of failures when the memory consumption goes to todays level. In practice, on my local machine the fuzzer is working fine even with a 100MB limit (I can see rss staying below 100 mb without a crash).

I'm not sure why that is (I assume at the limit the process might be able to free some otherwise "allocated" memory or the majority of memory comes from input data).

### Test Plan
Ran locally and didn't see crash in ~1 hour of testing. Plan to use argument in staging config and see fuzzing pod not run cause resource limit warnings in slack.

13801 of 56050 branches covered (24.62%)

Branch coverage included in aggregate %.

3804 of 5963 relevant lines covered (63.79%)

39699.83 hits per line