* libafl: Remove `{update,clear}_hash` from `ObserverWithHashField`
These methods aren't used by `NewHashFeedback`, so there's no compelling reason
to keep them in the interface. They preclude implementations of
`ObserverWithHashField` that calculcate a hash on-the-fly from a value. For
example, my use-case is to store the stdout of a process, and use
`NewHashFeedback` to only collect inputs that result in new messages on stdout.
Both of these methods are pretty suspicious to begin with - why should other
code be able to update the internal state of the observer? What are the
semantics of `update_hash`? If there are compelling reasons to keep these
methods, let's clarify their intent in the documentation.
* libafl: Return hash by value from `ObserverWithHashField`
This allows implementors of this trait to not store the hash, but rather to
compute it on-the-fly. Since `Option<u64>` is `Copy` (and quite small), and
this method is called once per execution of the target program, this is likely
to have negligible performance impact.
* libafl: Implement `ObserverWithHashField` for `ValueObserver`
This demonstrates the utility of the previous two commits. Now, `ValueObserver`
can be used with `NewHashFeedback`.
* Clippy, move to ahasher
* Oops :)
---------
Co-authored-by: Langston Barrett <langston.barrett@gmail.com>
cc53da85fb