feat: draft MR establishing the reporter package

This MR introduces the higher-level abstraction of the Reporter into Labkit - the intention here is to provide an over-arching abstraction that encapsulates the complexities of our logging, metrics, and future tracing configuration and ensures we're consistently following internal standards.

I've done a write-up of the future vision I have for this Reporter construct here - gitlab-org/quality/go-service-template!6 with some examples as to how we'd expose logging/metrics/and traces in the future.

I've intentionally stripped back the code from that example into something that directly tackles the problem that the Cells team are trying to urgently resolve.

Note - this still needs tests and documentation, but given the urgency of the request, I'm wanting to get alignment from folks first prior to investing more significant time into this.

Example Usage

The most powerful way to highlight the benefits here is through an example bit of pseudocode:

import (
  "labkit/grpc" 
  "labkit/reporter"
  "domain"
  "gitaly"
)

func main() {
    reporter, err := reporter.New(ctx)
    // handle err

    gitalyClient, err := gitaly.NewClient(reporter)
    // handle err    

    domainService := domain.New(gitalyClient, reporter)
}

// gitalyClient


func NewClient(appReporter reporter.Reporter) (&Client, error) {
  grpcClient, err := grpc.NewClient("target-from-env-vars", reporter)
  // handle err  
  return Client{
    grpcClient
  }, nil
}

func (g *Client) Commit(ctx context.Context) {
  g.grpcClient.MakeRequest(ctx, requestPayload)
}

The outcome of this approach is that we have a developer who has been able to instantiate a grpcClient that is instrumented in a minimal amount of code. Should they need to tweak the grpc connection for any reason, the API that I've designed is extensible and offers that flexibility.

More importantly, it allows us to re-use the MeterProvider in the reporter and eventually extend this interface to allow for methods such as Incr Decr Timing Guage which are shallow wrappers around standard types of metrics you'd typically instrument your application code with.

The Chocolate Cookie Architecture

Whilst this might seem a little overly opinionated in terms of abstracting away these constructs, I do feel that this pattern is going to become increasingly important as we start to move away from the monolith with the introduction of the Chocolate Cookie Architecture that's being established.

The current expectation is that we'll be building servers that expose multiple services. These services will need to be instrumented following a consistent pattern so that we can start templating things like our dashboard setup and really addressing some of the most critical concerns raised in the DX survey.