Allow Envoy gRPC access log service to be dynamically configured

[bplotnick]

Title: Allow gRPC access log service to be dynamically configured

Description:
Currently, the gRPC ALS cluster is required to be a static resource. This is because config.accesslog.v2.CommonGrpcAccessLogConfig.grpc_service is of type core.GrpcService and core.GrpcService.EnvoyGrpc is required to have a cluster_name that points to a static cluster.

Is there a compelling reason for the ALS cluster to be a static cluster. Perhaps this makes sense for core.ApiConfigSource, which is the main user of core.GrpcService, and was just brought along for the ride when ALS was added?

[mattklein123]

The reasoning here is the same that ultimately lead to #2966 for ext_auth. Basically, IMO, allowing the logging cluster to come and go can lead to more brittle configs, since in many cases it makes no sense for the logging cluster to be removed. I'm strongly against generically allowing this for all grpc_services, but if people want a generic option we can do that.

[bplotnick]

Thanks for the reference! In reading the related issues, I realized that this concern is actually not relevant for my use-case. For some reason I thought the endpoints had to be static as well 🤦‍♂️

For the general case, i don't fully understand the factors at play. I assume #2762 is the center of discussion for this, so I'll close this issue.