Separate history engine factory from handler

[yycptt]

What changed?

• Separate history engine factory implementation from history handler
• Clean up some unnecessary parameters after the separation

Why?

• Existing initialization logic contains a cycle: history handler depend on shard controller, but shard controller needs to use history hander as the engine factory. This is currently done via fx.Invoke and quite confusing when reading the code.
• New dependency graph will look like the following: various resources -> host level components -> shard controller and engine factory -> history handler.

How did you test it?

• Run sample locally

Potential risks

Is hotfix candidate?
no

[wxing1292]

can we get rid of the history engine factory?

[alexshtin]

CreateEngine is trivial. All fun stuff is in NewEngineWithShardContext which is actual factory. I would leave factory as its responsibility is clear: create engine per shard, which can't be done use fx during server start. But I would:

1. Rename NewEngineWithShardContext to NewEngine and make it trivial constructor (assign fields with passed values),
2. Move most of the code from NewEngineWithShardContext to CreateEngine. All New* calls should be either in factory or in provider.

You can do this in separate PR.

[yycptt]

can we get rid of the history engine factory?

All fun stuff is in NewEngineWithShardContext which is actual factory.
All New* calls should be either in factory or in provider.

Looks like we have some quite different opinions around whether or not engine factory is needed or not and exactly what should be done there. It's probably a good idea to have some discussions and reach consensus before I making further, bigger changes.