[WIP] Opportunistic state merging for Manticore

[vaibhavbsharma]

This PR is a work-in-progress as of now. The central idea is to merge states that happen to be at the same program location. This requires us to implement a is_merge_possible predicate that compares two states and a merge method that creates a merged State from two mergeable State objects.

I am still working on finishing the implementation of is_merge_possible by adding checks for the array of byte values in various Map objects that describe the state's memory. The next step is to implement the merge method by merging just the CPU and copy everything else from one of the two states.

So far, the changes affect the main loop in Executor. But, I am waiting for 3 APIs to be implemented that will allow me to move my code out of Executor and into a separate state-merging plugin. The design of the APIs is as follows:

1. load_state loads a state given a state_id without deleting it.
2. delete_state deletes a state given a state_id
3. replace_state replaces the state with a value state_id in its workspace with another state given in its argument
   All three APIs return an error if the state with state_id does not exist in Executor's workspace. @feliam is currently working on implementing these APIs.

With these APIs implemented, I plan to create a state-merging plugin that adds a callback for will_load_state. The callback would merge the state that is about to be executed with other states if any happen to be at the same program location. To figure out which states are at the same program location without loading all the states into memory, the plugin would add a handler for did_enqueue_state and maintain a global dictionary that maps state_id values to that state's program counter.

---

This change is 

[yan]

If you're okay including name in comparisons, this can just be if m1 != m2:

[vaibhavbsharma]

Yes, I didn't realize most of this check is already implemented in Map.__eq__. I've changed my implementation to just use m1 != m2.

[yan]

Map.__lt__ uses start to sort by default (and then end, perms and name, in that order)

[vaibhavbsharma]

I didn't realize that. Thanks for letting me know. I've dropped the key parameter from these sorted calls.

[disconnect3d]

Or just for i, j in zip(buffer1, buffer2):

[yan]

This also only checks the first len(buffer1) bytes (or min(len1,len2) bytes in the updated case); is that by design?

[vaibhavbsharma]

Thanks for catching this. I was planning on adding the check for the two buffer lengths to be equal but I forgot about it when looking at other parts of the State. I've changed the implementation to check the lengths for equality and using zip.

[CLAassistant]

All committers have signed the CLA.

[disconnect3d]

Loud thinking: do we want users to directly subscribe for events? @feliam

[disconnect3d]

Delete comment?

[ehennenfent]

Closing this as it's now being tracked in #1482