Organize chronicle exporter by http and grpc

[djaglowski]

This PR contains many changes so it may be wise to chunk it out into smaller changes. However, I'm opening it as a draft in order to facilitate feedback on the overall direction.

Changes included:

• Separate "http exporter" and "grpc exporter".
• Host metrics collection code is more clearly limited to the grpc exporter.
• Separate marshaling code & deletes mocking of marshaler. We shouldn't be mocking things that are end-to-end testable in a local environment.
• Implement mock servers to maximize code coverage. Specifically, this allows us to exercise most of the client code.
• It's still necessary to mock a few functions, basically limited to building endpoints and bypassing authentication.

Future work:

• No changes to configuration for the sake of backwards compatibility. However, it's quite clear that having all configuration at the same level in a single struct makes it difficult to logically enforce the rules. We can consider whether to migrate this later.
• This does not yet include tests for splitting payloads, but we should be able to add them more easily now, since we are not mocking the entire clients.

[mrsillydog]

Maybe just me, but calling this file util_test.go makes me think that it's a test file for util.go, not a util file for test files. test_util.go?

[djaglowski]

Yeah, that's fair. It probably doesn't need to be a separate file at anyways.

[djaglowski]

This code ended up only being used only in the http tests, so I moved it there instead.

[mrsillydog]

Could be a later adjustment, but worth trying to break this out into a GRPC protoMarshaler and an HTTP protoMarshaler? The methods on protoMarshaler are largely only used by one of the two workflows.

[djaglowski]

I think you're probably right. I'll take a closer look at this.

[djaglowski]

I split the marshaler into a base struct, and separate http and grpc marshalers, and moved them into an internal package to ensure testing is clean.

[mrsillydog]

This happens in both exporters but is only used as a parameter to newProtoMarshaler - if we don't split protoMarshaler into two, worth getting rid of that parameter and just doing the UUID parsing in newProtoMarsheler?