feat: mutation testing setup

[alexanderbez]

First stab at mutation testing using the go-mutesting tool/binary.

A quick summary of mutation testing and the output the binary produces:

• Mutation testing attempts to modify a program or binary, which are called mutants, and executes existing tests against those mutants.
• If tests fail, the mutant is considered "killed".
• Having mutants killed is a good thing, which means the software properly tests the various possible execution paths and should lead to strong confidence levels in the program's correctness.
• The go-mutesting produces an output such as the following: The mutation score is 0.750000 (6 passed, 2 failed, 0 skipped, total is 8). This means 6 mutants were killed yielding a score or confidence level of 75%, which is not terrible. The higher the score the better.
• False positives are probably going to be a common, i.e. a mutant that isn't killed but should be ignored. The most common example is "early exits" in a function/method. These are going to be pretty common I imagine and need to be added to a "blacklist" file that we will maintain as times goes on.

This PR sets up the scaffolding in CI for mutation testing and uses various parts of x/tokenfactory as the starting point. Subsequent PRs should be made which add more and more files/packages to be executed. Note, if the confidence score is low, that means our tests are not sufficient and should be improved prior to merging said PR.

[ValarDragon]

Is there some sort of conflict happening with these colors? (Feels a bit odd to me to commit color preferences in the vscode config 😅 )

[alexanderbez]

I wanted to commit these for use with Peacock but oh well, reverted :(

[ValarDragon]

This is some interestintg file specification syntax lol

[alexanderbez]

lol this took me ages to figure out FYI

[ValarDragon]

This is awesome! Ran the script for the token factory module, and this seems like qutie valid testing gaps found!

(That we currently aren't verifying codec changes, which even led to concerns on PRs #1972 #1994 )

Only errror type I;'m struggling to understand right now is:

-
-	_, err = GetTokenDenom(m.Sender, m.Subdenom)
+	_, _, _ = err, m.Sender, m.Subdenom
 	if err != nil {
 		return sdkerrors.Wrap(ErrInvalidDenom, err.Error())
 	}

wdyt the steps here should be? (Beyond understanding ^ and if its a false positive)

I feel like going ahead and merging this, and then maybe making CI run this on a schedule (perhaps once a week at first?) for a couple modules, and generate a list of failures into a github issue we tackle? (If details of that are hard, we can do so manually first couple of times)

[czarcas7ic]

@ValarDragon simulation is failing in CI (and locally) every now and then when the simulator decides to use the same lock ID twice. I can look into it, but for now if we rerun this should clear

[ValarDragon]

Really excited about this!