This wasn't too bad, though the variable names disappeared from the
go-parsed type signature of our RPC specs so I had to generate variable
names manually /shrug

Google's protobuf compiler doesn't allow you to customize JSON
formatting and forking it like we did with gogo's is no simple
matter (it depends on a large number of internal packages...).

I'm deleting it for now to unblock myself while I wait to discuss this
with our HTTP API team tomorrow

Props to sed for existing

Go's protobuf-generated code embeds locks, so by copying the contents of
the object we violate the lock's guarantees. We'll return the new
payload and overwrite the old instead

The files changed name, whoops.

We'll want to use this in the CLI as well to allow users to update old histories

There's one option and its pretty much always supplied; this was an
over-eager change.

Pulled these over form the SDK and cleaned up the naming.
common.ThingPtr and common.ThingValue don't roll off the tongue as
nicely as thing.Proto and thing.Value.

Filter out non-go files and make sure to rewrite uses of these enums

Tests are now run by default (as they should be)

We're back to proto for codegen too

My previous approach failed to fix enums in nested failures.
Rather than hardcode logic for handling failures specifically I took a
step back and approached it another way entirely: tracking paths to fix
for each proto message that is reachable from the History message.

With this approach we can handle any future type that can contain itself
without code changes

It turns out we serialize far more than just history in JSON so we need
a mechanism to support the old enum format for arbitrary proto objects.

The approach I've taken is thread-safe so we don't need to care who is
serializing what at any point in time (and I've minimized the critical
sections). Most operations will only ever take the registry's read lock
so this shouldn't be a bottleneck

This package will eventually contain all our extensions to google's v2
proto package, including:

- Enum casing translation
- Shorthand JSON support

I discovered _even more_ places where we use our PascalCase enums so
we'll just generate the code needed to handle it.

We rely on the old JSON string values of our proto enums heavily; they
appear in error messages, the visibility search interface, and our
metric tags.

Rather than rewrite them at every callsite we decided to simply rewrite
the String methods to give us what we want. This is lower effort and
less maintenance than maintaining a fork of the protojson marshaling infrastructure.

This will be go-installed by the Server so needs a more obvious name.

These are becoming necessary elsewhere

It's all proto's fault anyways

I've no idea why these two mocks keep swapping names. It's irritating

This is only used by the server so should stay there