Consider using a faster base64 codec

[2opremio]

https://github.com/cristalhq/base64 seems to do a much better job than the standard codec.

[leighmcculloch]

Interesting. I wonder if there is also a better base32 implementation out there. I managed to optimize keypair package a lot, but the strkey package that uses the base32 package is expensive.

A quick search of the golang/go repo shows that nobody has discussed the cristalhq/base64 package. There could be value in seeing how the improvements noted there could be translated upstream into a more performant encoding/base64 implementation. We could contribute that, open an issue, propose assimilating the same principles upstream.

A couple things concern me about cristaylhq/base64:

1. Its readme says:

   • Drop-in replacement of encoding/base64.
     • except for error messages and ignoring \r and \n in decoder.

   It's not a complete drop-in replacement, so there could be behavior change.

2. It appears to use unsafe. There is no compatibility guarantee for unsafe usage from one version of Go to the next, so using that package could hamstring our ability to quickly upgrade to new Go versions. We don't currently have any dependence on unsafe outside of the stdlib. That's something of a luxury we have right now and I'm not sure it's worth us giving that up.

[2opremio]

There is also https://github.com/segmentio/asm/tree/main/base64