Refactor queryRecordsInBatch to broadly support varying batch sizes

Type of change

• Bug Fix
• Feature

Please provide link to gitlab issue or ADR(Architecture Decision Record)
#577 (closed), #580 (closed)

Does this introduce a change in the core logic?

• [YES/NO]

Does this introduce a breaking change?

• [YES/NO]

What is the current behavior?

• Dependency on batchSize being less than 1000 or a multiple of 1000.
• Ignore Kind's batchSize unless using specific workflow
• Default Kind's batchSize to 5 in the event where Kind batchSize is not defined, but sometimes this value is ignored or overwritten depending on the workflow.
• Log the batchSize before it has been overwritten, sometimes leading to a misleading log about the current batchSize in use
• wellLogStep is a required value, and defaults to 100 even when it is not relevant for this Kind's workflow.

What is the new/expected behavior?

• batchSize may be any value greater than 0 and the batches will adjust accordingly.
• If Kind batchSize is not set (i.e. 0) and the user has not activated an advanced workflow (spatialSource, completeTrajectory, or certain geometryLocations), then the default Transformer batchSize will be used.
• If Kind batchSize is not set (i.e. 0) and the user has activated an advanced workflow (spatialSource, completeTrajectory, or certain geometryLocations), then the batchSize will be overwritten to lower default.
  • spatialSource = 300
  • completeTrajectory, generatewellboremarkerpoints, generatewelllogline = 5
• If Kind batchSize is set, use that value always, with priority.
  • As an advanced option, this will override all other batchSize guards for the Kind, regardless of workflow
  • This gives control to admins to optimize their batch loading to a value better suited for their environment, if our conservative defaults are not ideal.
• Log batchSize only once batchSize is certain, so logs align with actual work.
• If Kind wellLogStep is not set, it defaults to 100