Simplified ScheduleManager and renamed it to InboundBatchAggregator

[agarwal-navin]

Renamed ScheduleManagerCore to InboundBatchAggregator because its primary objective is to ensure that an incoming batch is fully available in the delta queue before it starts processing.

Also, simplfied it as following:

• Removed ScheduleManager because all it was doing was calling DeltaScheduler and emitting batchBegin and batchEnd events. Moved this directly into container runtime which was recently refactored to consolidate this logic in one place.
• Removed the logic to modify batch metadata in delta manager's prepareSend event handler. This is an artifact of very old logic where adding the batch metadata was distributed between container runtime and delta manager. For a long time now, container runtime is in full control of adding (or not adding) batch metadata to messages in a batch. This was done by Move batch processing logic from loader to container runtime #11832.
• Removed the scheduleManager.spec.ts unit tests. All it was doing was validating batchBegin and batchEnd events which is the same as the ones done in batching.spec.ts unit tests. Moreover, it was using custom logic to identify batch beginning and end from the inbound messages so it wasn't really testing any real code.

 
AB#1981

[agarwal-navin]

This is not needed because the logic inside it can be done in the constructor of InboundBatchAggregator. However, it doesn't have any public members so the alternative would be to not have a member in container runtime for it and do something like void new InboundBatchAggregator ..." similar to how ScheduleManagerCore` was used.

[ChumpChief]

I'd probably suggest moving the setupListeners content into the constructor as you mention, otherwise the constructor returns a kind-of-wrong object.

InboundBatchAggregator should really probably have a public dispose() that unregisters those listeners which would be the reason for retaining a reference rather than voiding it (to call this.inboundBatchAggregator.dispose() when the ContainerRuntime disposes).

[agarwal-navin]

Good suggestion. I added dispose.

[agarwal-navin]

Note that this logic is not needed any more because container runtime handles this before it sends the batch to delta manager. See PR description for more details.

[ChumpChief]

I love it - would suggest moving the event setup stuff into the constructor though.

If you don't pursue a dispose() in this PR and stick with the void, maybe just open a task/todo.

[kian-thompson]

Suggested change

	* that we never start processing ops in ab batch IF we do not have all ops in the batch.
	* that we never start processing ops in a batch IF we do not have all ops in the batch.