Cleanup of runtime code

[kenluck2001]

This PR refactored the source code to remove these concepts from repo: #4691

TreeEntry.Commit
"commit"
ISnapshotTree.commits

Not sure if if #4683 is fully covered too

[ghost]

All CLA requirements met.

[msfluid-bot]

■ @fluidframework/base-host: No change

Metric Name	Baseline Size	Compare Size	Size Diff
main.js	187.08 KB	187.08 KB	■ No change
Total Size	214.67 KB	214.67 KB	■ No change

⯆ @fluid-example/bundle-size-tests: -409 Bytes

Metric Name	Baseline Size	Compare Size	Size Diff
container.js	162.13 KB	161.97 KB	⯆ -172 Bytes
map.js	44.74 KB	44.66 KB	⯆ -79 Bytes
matrix.js	143.54 KB	143.47 KB	⯆ -79 Bytes
odspDriver.js	175.31 KB	175.31 KB	■ No change
odspPrefetchSnapshot.js	38.98 KB	38.98 KB	■ No change
sharedString.js	165.12 KB	165.04 KB	⯆ -79 Bytes
Total Size	762.5 KB	762.1 KB	⯆ -409 Bytes

---

Baseline commit: 2ca9937

Generated by 🚫 dangerJS against c270260

[tylerbutler]

@kenluck2001 Thank you for this PR and #6876 ! There's an internal event at Microsoft this week, so you may not see any feedback on these PRs until next week. Just wanted to let you know we're not ignoring these. :)

[vladsud]

@jatgarg, can you please help with CR here? Specifically, assess if cleanup can be done across server/client in one go (i.e. I'd think we want to build repos linked together to prove correctness).
I'm also not sure about connection to ISnapshotTree.commits and ITreeEntry.type === "commit" (see for example buildHierarchy). Do we need to remove ISnapshotTree.commits as well to ensure that we are not missing anything and cleanup indeed is possible, mechanical and has no impact on existing functionality?
Some context - Kenneth is helping here as part of his FHL project, he is new to FF.

@tanviraumi - please glance as well, I'm surprised a bit it's so easy :) Does R11S need to retain any of the logic related to commits? From quickly glancing through code, it feels like we do not use commits at all nowadays and we can do cleanup (including wiping out commits from ISnapshotTree).

@kenluck2001 - some context for you: We have 3 separate builds as part of repo - common, server, client. They depend on each other through versioning mechanism. I.e. changes you are making here on the server side are not consumed in same build by client build - client keeps using old definitions, until new server packages are published and client bumps dependencies (versions in package.json) to consume them. So while build succeeded, it does not prove that all commit references (on client side) are removed - we may find surprises down the road when client consumes these new server bits.. Thus I'm a bit worried this is not complete fix, and a bit more involved validation might be required. We have certain ways to simplify such validation (by linking builds together), and that's required to prove to ourselves that indeed direction is right, but it is a bit involved operation

[curtisman]

Ping @jatgarg @tanviraumi

[tanviraumi]

FYI @znewton

[jatgarg]

I am trying to test these changes on my local box.

[jatgarg]

Added some changes. The previous changes also look fine to me. Ran snapshot tests with these changes. So approving. We can merge once @znewton also approves this.