UpdateInStore fails when log updates contain a data range larger than WitsmlSettings.LogMaxDataNodesGet

[nilsabenson]

If you have an existing log with a fair amount of data and try to push in an UpdateInStore that contains an ending data point that exists beyond the rows fetched by WitsmlSettings.LogMaxDataNodesGet in ChannelChunkAdapter the update will succeed, but leave the data in an unusable state.

When the update happens, ChannelChunkAdapter is used to rip through the existing data looking for the chunk that the updates should belong before/in/after. However, if your update contains a range of data that requires it to look beyond the WitsmlSettings.LogMaxDataNodesGet count of rows it will mistakenly think that it needs to put it into the wrong chunk (because it assumes that it will find what it's looking for but doesn't because of the hard limit).

The update will technically succeed, but querying the data from the log moving forward will fail because the chunks are no longer in order.

We are proposing to add something like a Func to be used for this query that allows for slightly different behavior based on what you actually want. For GetFromStore having a hard limit is OK, but for UpdateInStore we need to make sure that we inspect everything before updating the database without a hard upper limit.

This would also allow for functionality as requested in #1 where output row counts can be controlled by dataRowCount on the GetFromStore query.

[nilsabenson]

moving this issue to witsml repo - this is where it actually exists