Gitrest: initial write speedup

[znewton]

Description

When using a remote filesystem, the overhead of filesystem operations makes shredded summaries extremely slow to read/write. We already work around this for Read by computing and storing a latest "Full Summary" single file that is used on read for most "Latest" summary reads.

The only Summary Write operation in the critical path is when creating the initial summary for a new document. This PR attempts to reduce the overhead of a shredded summary read/write by "compressing" the git tree for the initial summary into a single file (using Isomorphic git with memfs).

Breaking Changes

N/A, only impacts new documents

Reviewer Guidance

I validated the following scenarios to ensure functionality with each enableLowIoWrite setting ("initial", true, false) as well as forward/backwards compatibility using local R11s and my fluid app.

• Write service summary from initial summary
• Write client summary from initial summary from first client
• Write client summary from initial summary from 2nd client (no service summary in the middle)
• Write service summary after client summary(ies)
• Write client summary after service summary(ies)
• Load from service summary
• Load from initial summary
• Load from client summary

[yangg-msft]

Generate a metric to capture tenant id, doc id, content length, and processing time? #Closed

[hedasilv]

Or if we want to keep this as a long, we can also add those properties in the properties parameter for Lumberjack.info().

[znewton]

I removed most of these inner logs, but added additional properties to the wrapping summary write metric that will help us understand each one in our telemetry (newDocument, commit/tree sha, and enableLowIoWrite).

[hedasilv]

This is great! Thanks for working on this. I have a few questions to help me understand the overall flow.

1. In writeContainerSummary(), an in-memory repoManager is used as a way to obtain the full summary associated with an initial summary upload. Traditionally, we would have very high I/O latency because internally, GitRest would break up the initial summary payload into small Git objects, and upload each one of them individually to the chosen filesystem. The trick here is, then, to do exactly the same, but instead of using the original filesystem, have the uploads happen to an in-memory filesystem. By uploading the Git Objects to the temporary, in-memory repoManager, and later reading from there, we end up computing the full summary without the need to make multiple network calls. And then, once we have the full summary in hand, we write it as a single blob to Git. Is that correct?
2. What happens to that initial full summary blob on subsequent summary writes? My current understanding is that on a subsequent incremental summary write, the full blob would be read from storage and parsed so GitRest and compute the incremental diff. Once that is done, it will generate Git objects (blobs, trees, commits and refs) as usual, uploading them in a "shredded" way to the repoManager/storage as usual, since this is not the critical path anymore. As a result, the initial full summary blob would not be referenced again, and would have to be eventually garbage collected (once that is available). Is that correct?

[yangg-msft]

[znewton]

Merging because confident in correctness (tested with R11s and FRS extensively). Also, new functionality is hidden behind a feature flag, so it will only be enabled in intentional scenarios.