Proposed Map Hammer Model

[Martin Hutchinson]

The Map hammer (/testonly/hammer/hammer.go) kicks off two flavours of thread:
A) read-only checker thread
B) read/write thread

Any number of type A can be kicked off, and one of B is kicked off. In principle this shape will be kept, but some of the operations in B will be moved to A; currently A only performs GetAndVerifyMapLeavesByRevision with random revisions. Type B will perform a number of operations from SetLeaves to fetching SMRs.

More specifically, the proposal is to make:

• Type A use only the Map Read API and exercise the operations on there according to the biases in the configuration
• Type B to use only the Map Write API and perform work on there which more closely represents typical sequencer/write personality workflows

This change more accurately reflects what entities will do in the real world, and allows for scaling and testing the load of the write vs read characteristics far more cleanly.

[Martin Hutchinson]

TBD whether the main thread should only use operations from the write API. This better represents what happens in the real world, but it means that a hammer invocation with no checkers doesn't exercise many of the methods. I suggest changing the default checkers to 1 and making the main thread use only methods from the Write API.