Does this demonstrate improved performance on the ParseMessage benchmark?

Its a lot simpler so it would save on maintenance.
Just be weary that sometimes the no-contention mechanisms mean its eventually consistent (buffered writes or delayed writes) which might pose problems with direct set and get code.

I just benchmarked and it seems that id does not work better. I suspect the issue is with haxmap doing initial allocation that is more slow while working on existing haxmap is a lot faster. But since we create lots of haxmaps it is actually not faster.
I tested the performance with and without rwmutex:

without rwmutex:
BenchmarkParseMessage-16 	 2524971	 480.8 ns/op	 20 B/op	 2 allocs/op
with rwmutext:
BenchmarkParseMessage-16 	 2283403	 528.4 ns/op	 20 B/op	 2 allocs/op
with haxmap:
BenchmarkParseMessage-16 	 843738	 1353 ns/op	 1536 B/op	 34 allocs/op

The issue that we actually had with parsing is not related to rwmutext but to repeating_groups because they are parsed on each get and it's taking 30% of our processing:

I will do another PR to try to solve this.