gitrest: lazy repo init

[znewton]

Description

A large percentage of AFR docs never write a 2nd summary after the initial summary. That means the effort to create a fully versioned Git repo is wasted effort and storage for those cases.

We can leverage existing logic to store the initial summary as 1 blob without a Git repo, then create a Git repo with a backfilled initial summary if a subsequent summary is written.

This should reduce the number of storage accesses by >80% for initial summary creation, and reduce storage volume by 50% for scenarios with only 1 summary. The reduction in storage access will result in a massive performance gain and cost reduction for remote filesystems.

Reviewer Guidance

1. The existing unit tests for summary writes don't hit this new logic because it is at the API layer. I'm thinking about how to do this in a better way. In the meantime, I performed extensive manual testing for the following summary scenarios:
   1. Initial->Client->Client->Service
   2. Initial->Client->Service
   3. Initial->Service->Client
   4. Initial->Service->Service
2. All the logic being spread across the HTTP API implementations is a bit sloppy and difficult to test. Expect this to be refactored.

[microsoft-github-policy-service[bot]]

This PR has been automatically marked as stale because it has had no activity for 60 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!