Tune up Fuzz test

[cameracker]

Several years ago, @acln0 contributed a fuzz test to the package It was incorporated prior to github actions, and was not integrated into travisCI (what we were using at the time), so it hasn't made it into our CI. Additionally, the way it's invoked involves installing dvyukov/go-fuzz using go get - it's not included in go.mod. And, go provides fuzzing functionality directly as of Go 1.18.

We should touch this up. Fuzzing is a valuable testing practice, and even if we don't find much because our parameterized functions are so minimal, it'd still be useful to cover our bases.

I suggest fuzz testing should look like

• We have fuzz testing for our string parsing functions (implemented today)
• We have fuzz testing for any functions that take user input, unless its a complicated input (like passing a custom generator)
  * We run this fuzz test for 30 seconds during CI
• We use the go fuzzing functionality, move off of go-fuzz

Interested in with others think!

[dylan-bourque]

The only thing I would push back on is running active fuzzing (generating new input values) during CI. We should definitely run active fuzzing and commit any edge cases it finds alongside the fixes, but no one likes it when their CI build fails for something unrelated to their change.

[cameracker]

Fixed in #148