Overlapping refresh and datapoint transactions

[error1100]

Sometimes datapoint transactions overlap with refresh transactions, leading to the datapoint being excluded from the refresh transaction. This is now more prominent with shorter epoch lengths for DORT. There is need for optimized logic controlling datapoint submission around epoch changes.

[error1100]

One of many examples:

Valid datapoint tx for epoch 200, the reported value is the same as other oracles (not an outlier). https://explorer.ergoplatform.com/en/transactions/91f2d84f4f1d16115ccec5401c8102b7d41ba7ae1b18756b55956c5323679e10

Excluded from refresh tx for epoch 200, while all other later published datapoints where included.
https://explorer.ergoplatform.com/en/transactions/f4aa277088923dadd237d29736fbf964321a718f54d3a2d206de643491619b05

This happens mostly with datapoints created in the beginning of an epoch. I suspect it has to do with the creation height vs settlement height difference which pushes some datapoints out of the epoch window. The smart contracts and and oracle code make use of current height and repost refresh txs on every height change. If the tx is not settled immediately, on next height older datapoint txs can fall out of range because of the current height - creation height diff. In this case the difference was +3 between creation height and settlement height for the datapoint tx, so the real diff between current height and creation height becomes 9 (6 epoch length + 3 diff). The new refresh tx without the datapoint tx (lower fee/bytes) replaces the tx published one block back which included the datapoint tx .

The simplest change would be that oracles always post in the second half of the epoch, even if the epoch has not changed, i.e. no refresh tx was published. This ensures that whenever a refresh tx will be published it will find the minimum required boxes in its current height - epoch length interval.