Simplify the DbEntityReader/DbEntityWriter subsystem

[Turnerj]

While initially I thought it was best to separate the DbEntityReader and DbEntityWriter from the MongoDbSet, it doesn't seem as clear anymore to have this distinction.

For example, the DbEntityWriter really acts as an API that just gets in the way of calling the internal methods on the collection (InsertMany, DeleteMany etc). It also has code that references the DbEntityEntry class.

It does serve one nice purpose, it is how the mutation functionality is called but that could be restructured too.

What would be better is if there was something dedicated to converting the items in the DbChangeTracker into an IEnumerable<WriteModel<TEntity>>.

Besides I think more fitting for what I'm really trying to achieve here, it allows easier targeting of async against the MongoDb driver - specifically, it makes using the BulkWrite function a little easier.

To get here, I think a few things need to happen:

• Split the IDbChangeTracker interface to have a lower level "container" where it has all but the DetectChanges method
• Create a new DbEntityWriteComposer class, have that do the conversion from the items (through our new "container" interface) to the IEnumerable<WriteModel<TEntity>> data
• Rip apart the DbEntityWriter class to just have Write and WriteAsync functions which take the enumerable mentioned above
• Change the MongoDbSet class to take the data from the "container" (implementation here is still the change tracker), use the "composer" and the re-written DbEntityWriter to push the changes to MongoDB

I still need to think about applying the mutation changes - where are they going to go?

[Turnerj]

The main work for simplifying the DbEntityWriter is done. Entity mutation is still called from the writer.

Regarding the previous comment about a write composer, at this stage it felt like overkill but it may be something I look at in the future.

The implemented change doesn't pass around the IEnumerable<WriteModel<TEntity>> publicly like I mentioned either - instead this is built internally in the writer. The writer can do this because it is passed an IDbEntityContainer<TEntity> and can work out the changes required to write.

The change tracker extends this new entity container class.