[access log] Refactor gRPC access logger to support log sinks with different proto messages

[yanavlasov]

Commit Message:
Refactor gRPC access logger to support log sinks with different proto messages

Additional Description:
This is pre-requisite change for adding OTLP access logger. This change refactors functionality common to all gRPC loggers into a set of template classes parameterized with protos of log entries and gRPC request and response messages.

Refactored functionality:

• base class for creating gRPC access log connections.
• cache of gRPC access log connections

As the OTLP access logger is being added these classes may be modified and more of the shared code may be moved.

Risk Level: Low (refactor)
Testing: Unit and Integration Test
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: None

Part of #13801

Signed-off-by: Yan Avlasov yavlasov@google.com

[itamarkam]

I don't mean to hijack this review, I was just curious to see how you templated all of this -
Does it make sense to also split the TCP and HTTP logging?
There's nothing specific to HTTP/TCP in this interface and it would allow creating a logger that does only one of the two.

[yanavlasov]

We can not split it as such but we can provide partial specialization for the GrpcAccessLogger that has only one log method, instead of two. There is currently no use case for it now, but it can be added as part of adding OLTP logger if it only supports logging one type of log entry.

template <typename LogProto> class GrpcAccessLogger<LogProto, void> {
public:
  using SharedPtr = std::shared_ptr<GrpcAccessLogger>;

  virtual ~GrpcAccessLogger() = default;

  /**
   * Log access entry.
   * @param entry supplies the access log to send.
   */
  virtual void log(LogProto&& entry) PURE;
};

[zuercher]

lgtm