build(client): Clean up changesets for 2.23 release (#23895)

Author: tylerbutler

.changeset/afraid-snails-speak.md

@@ -5,7 +5,10 @@
 "section": feature
 ---
 
-Events added for local value changes
+Local value changes in presence now raise events
+
+The [presence value managers](https://fluidframework.com/docs/build/presence#value-managers) now raise events for local
+value changes. The new events are as follows:
 
 - LatestValueManager
   - `localUpdated` raised when `local` is assigned

.changeset/blue-plants-act.md

@@ -6,9 +6,12 @@
 "section": tree
 ---
 
-Faster creation of large transactions and faster processing of inbound changes
+Creating large transactions and processing inbound changes is now faster
 
 SharedTree sometimes composes several sequential changes into a single change.
 It does so whenever a transaction is created and when processing inbound changes.
-[This PR](https://github.com/microsoft/FluidFramework/pull/23902) makes this composition process asymptotically faster.
+
+Version 2.3.0 makes this composition process asymptotically faster.
 For example, creating a transaction that performs 1000 edits on a single array now takes 170ms instead of 1.5s (an 89% improvement).
+
+See [Change #23902](https://github.com/microsoft/FluidFramework/pull/23902) for more details.

.changeset/large-heads-jog.md

@@ -8,4 +8,8 @@
 
 Faster processing of events for large transactions
 
-[This PR](https://github.com/microsoft/FluidFramework/pull/23908) avoids the event processing time scaling quadratically with the change count when processing a batch of changes.
+In versions prior to 2.3.0, event processing time could scale quadratically (`O(N^2)`) with the change count when
+processing a batch of changes.
+
+This performance characteristic has been corrected. See change
+[#23908](https://github.com/microsoft/FluidFramework/pull/23908) for more details.

.changeset/purple-ideas-switch.md

@@ -6,13 +6,16 @@
 "section": tree
 ---
 
-Op bunching Performance enhancements in Shared Tree
+Op bunching performance enhancements
+
+`SharedTree` now takes advantage of a new feature called "op bunching" where contiguous ops in a grouped batch are
+bunched and processed together. This improves the performance of processing ops asymptotically; as
+the number of local ops and incoming ops increase, the processing time will reduce.
+
+For example, with 10 local ops + 10 incoming ops, the performance increases by 70%; with 100 local ops + 100 incoming ops, the performance increases by 94%.
 
-A new feature called "Op bunching" is added to Shared Tree where contiguous ops in a grouped batch are
-bunched and processed together. This improves the performance of processing ops asymptotically - with the increase in
-the number of local ops and incoming ops, the processing time will reduce. For example, with 10 local ops + 10 incoming
-ops, the performance increases by 70%; with 100 local ops + 100 incoming ops, the performance increases by 94%.
 This will help improve performance in the following scenarios:
+
 - A client makes a large number of changes in a single JS turn. For example, copy pasting large data like a table.
 - A client has a large number of local changes. For example, slow clients whose changes are slow to ack or clients with
 a local branch with large number of changes.

.changeset/real-doodles-draw.md

@@ -6,7 +6,8 @@
 "section": tree
 ---
 
-Invalid schema base classes in `Tree.is` now throw an error instead of returning `false`
+Invalid schema base classes in Tree.is now throw an error instead of returning false
+
 As documented in [`TreeNodeSchemaClass`](https://fluidframework.com/docs/api/fluid-framework/treenodeschemaclass-typealias#treenodeschemaclass-remarks), there are specific rules around sub-classing schema, mainly that only a single most derived class can be used.
 One place where it was easy to accidentally violate this rule and get hard-to-debug results was [`Tree.is`](https://fluidframework.com/docs/data-structures/tree/nodes#treeis).
 This has been mitigated by adding a check in `Tree.is` which detects this mistake (which used to result in `false` being returned) and instead throws a `UsageError` explaining the situation.

.changeset/tender-rabbits-speak.md

@@ -7,5 +7,6 @@
 
 The FluidDataStoreRuntime.process function is now deprecated
 
-A new function `processMessages` has been added in its place which will be called to process multiple messages instead of a single one on the data store runtime. This is part of a feature called "Op bunching" where contiguous ops of a given type and to a given data store / DDS are bunched and sent together for processing.
+A new function `processMessages` has been added in place of `process`. The new function will be called to process multiple messages instead of a single one on the data store runtime. This is part of a feature called "op bunching" where contiguous ops of a given type and to a given data store / DDS are bunched and sent together for processing.
+
 Note that `process` may still be called in scenarios where this data store runtime (Datastore layer) is running with an older version of data store context (Runtime layer) in the same client. This is to support Fluid layer compatibility.