Remove feature gates for flushmode and batchmanager

[andre4i]

closes #7365

This will be reviewed/merged after the respective experiments are concluded.

[andre4i]

Small update, @vladsud

The test infra changes have been split off and merged in a separate PR, to keep things nice and isolated.

There are two problematic tests with this change:

packages/test/test-end-to-end-tests/src/test/stashedOps.spec.ts@"doesn't resend successful chunked op"

• timeout. I investigated this before, but I can't find anything wrong with this. My suspicion is that without the batch manager and with flushmode.manual, this test may be irrelevant. Will disable it with an open issue and will follow up with Wes.

packages/test/test-end-to-end-tests/src/test/attachRegisterLocalApiTests.spec.ts@"Registering DDS in attached dataStore should attach it"

• which fails due to the new feature in testing to catch all errors:

         "after each" hook for "Registering DDS in attached dataStore should attach it":
     Error: Unexpected Errors in Logs. Use itExpects to specify expected errors:
[
  {
    "eventName": "fluid:telemetry:DeltaManager:OpenBatchOnDisconnect",
    "length": 1,
    "category": "error",
    "clientType": "interactive",
    "containerId": "20256d54-0cb6-4ba1-be82-2e541cf02fd0",
    "docId": "0d6e77f2-0cb4-44c1-ab4d-2147b2de61eb",
    "containerAttachState": "Attached",
    "containerLifecycleState": "loaded",
    "containerConnectionState": "Connected",
    "dmInitialSeqNumber": 0,
    "dmLastKnownSeqNumber": 0,
    "connectionStateDuration": 1220.784600019455,
    "loaderId": "ca374d26-f185-4b3e-838d-e47be4961193",
    "loaderVersion": "0.58.0"
  }
]

• what happens here is that the disconnect handler in the DeltaManager when the client reconnects due to read->write pushes the error event as there are ops in the queue.
• this seems harmless, as ops should be retried by the runtime anyway
• the failure was actually injected by this change and the new feature in the test infra uncovered it
• will try to change the test to avoid ending up in this situation
• I'm wondering if this event should be downgraded from error.. Maybe the current change would make it too chatty

[andre4i]

Actually, packages/test/test-end-to-end-tests/src/test/stashedOps.spec.ts@"doesn't resend successful chunked op" may be a legitimate concern. The behavior of the test is cryptic, as it fails because the ensuresynchronized call times out. But the reason for that is that the container does not fire the saved event -> because replayPendingStates cannot send ops -> because the container is not connected -> because it closed with 0x16f.

I believe this is because https://github.com/microsoft/FluidFramework/blob/main/packages/runtime/container-runtime/src/containerRuntime.ts#L2355:

            // Note: Chunking will increase content beyond maxOpSize because we JSON'ing JSON payload -
            // there will be a lot of escape characters that can make it up to 2x bigger!
            // This is Ok, because DeltaManager.shouldSplit() will have 2 * maxMessageSize limit
            if (!serializedContent || serializedContent.length <= maxOpSize) {
                clientSequenceNumber = this.submitRuntimeMessage(
                    type,
                    content,
                    /* batch: */ this._flushMode === FlushMode.TurnBased,
                    opMetadataInternal);
            } else {
                clientSequenceNumber = this.submitChunkedMessage(type, serializedContent, maxOpSize);
            }

as if the message is split into chunks, even if it was part of a batch, it won't be sent as a batch message from the perspective of its metadata.

[andre4i]

The feature gates are enabled and have been for the past few weeks. Production rollout is at 100%, so this code is safe to remove. I will do so before the release.

[vladsud]

I do not think there is a value in this event at all. I.e. it's either an error (i.e. we believe it should not happen), or it's normal flow that is handled, covered by UT, but really does not matter in terms of logging.
Also reason is not package data - it comes from socket (in majority cases) and we freely log it already.