Clear the gRPC log before running a deployment

[EronWright]

This PR adds a new utility method ClearGrpcLog and uses it to clear the log before a preview, up, refresh, or destroy operation. I'm unaware of any use case for retaining the event log across deployments, and forgetting to clear it may otherwise be a common mistake. If a use case emerges, assumedly one could copy the log before running the deployment.

[codecov]

Codecov Report

Attention: Patch coverage is 70.00000% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 37.25%. Comparing base (8c45fd2) to head (0808db7).
Report is 12 commits behind head on main.

Files	Patch %	Lines
pulumitest/grpcLog.go	25.00%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #67      +/-   ##
==========================================
+ Coverage   33.45%   37.25%   +3.80%     
==========================================
  Files          42       42              
  Lines        2571     2663      +92     
==========================================
+ Hits          860      992     +132     
+ Misses       1606     1565      -41     
- Partials      105      106       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[danielrbradley]

Having this facility to more easily correlate the log to a specific operation is definitely useful. Happy to merge this as a short term fix for now, though I'm much more interested in doing a small breaking change here to just include the log as part of each operation's result. I'll look to spike on what this would look like.

@t0yv0 any thoughts on this simple fix vs moving the log into custom response wrapper types?

[t0yv0]

IMO most realistic scenarios involve more than one deployment (you preview and refresh and up etc). By default PULUMI_DEBUG_GRPC is append-only so that's good to be able to capture the union of all of them, which deleting by default will prevent... I'm guessing it's not currently is not easy to separate out the logs from the one file since these log records are not labelled by deployment. Perhaps if PULUMI_DEBUG_GRPC could have some convention for disambiguating the operation phase so it becomes a file naming pattern that could be interesting.

ProgramTest does this for --trace. Exact same problem. When collecting benchmarks we needed to segregate the traces from each preview, up, destroy and so forth, so the flag is now not a file path but a pattern with {command} being substituted with a representation of what's happening, so multiple trace files are emitted from a single ProgramTest.

https://github.com/pulumi/pulumi/blob/master/pkg/testing/integration/program.go#L956

[EronWright]

I leave it to you both to make up your mind about whether to clear the log, but to @t0yv0's point, the log entries aren't adequately distinguishable across deployments. 99% case is that it should be cleared. A test could simply copy the log to retain the information.

[danielrbradley]

Let's put this in as-is and see it goes. Can always adjust later before we stabilize.