Summary:
Our original cloudapipb and vizierpb protos weren't actually in a state where we could make them public.
This diff creates new proto files for the protos that we do want to make public.
The changes are as follows:
CloudAPI:
- created new pl.cloudapi.public proto package for our public protos
- Created ClusterManager, which is a wrapper around the ClusterInfoService. This service excludes unnecessary functions such as creating/updating clusters. Users can GetClusters, which contains a subset of data from the original GetClusterInfo. ClusterManager also contains UpdateClusterConfig, which is a wrapper around the internal UpdateClusterConfig.
- copied APIKey/DeployKey services to the new public protos. *in the current state, this will break the old CLI, which points to the old API/DeployKey service.* the CLI, which is the only external place which uses these services, has been updated to use the new public proto. is it worth keeping the old service around for users with the old CLI, or should we just ask them to update?
Vizierpb:
- Renamed old, internal proto package to `pl.api.internal.vizierpb`, so that the public package can be `pl.api.vizierpb`, in hopes of maintaining backwards compatibility.
- Copied ExecuteScript/HealthCheck to new public package

Test Plan:
On Pixie Cloud with new API changes:
- deployed current release version of Vizier. verify that UI + new & old CLI can still query vizier. with new CLI, debugLog continues to work. with old CLI, debugLog does not work.
- deployed Vizier using skaffold. verify that UI + new & old CLI can still query vizier. with new CLI, debugLog works. with old CLI, debugLog does not work.

Reviewers: zasgar, philkuz, #engineering

Reviewed By: zasgar, #engineering

Differential Revision: https://phab.corp.pixielabs.ai/D7185

GitOrigin-RevId: f01d8a8a2d0d11256c308f3c4dcaf9b1c5a3b763