rpcdaemon: `ots_searchTransactionsBefore` returns duplicated transactions for multiple internal calls in the same tx

[sealer3]

Note: This issue similarly affects ots_searchTransactionsAfter.

Strangely, I'm getting both duplicate transactions and out of order results (see the block numbers) on this devnet smart contract:

You can recreate this by deploying a contract with this bytecode:

0x608060405260008055348015601357600080fd5b50610340806100236000396000f3fe608060405234801561001057600080fd5b50600436106100365760003560e01c8063653721471461003b578063b2041d2114610059575b600080fd5b61004361008a565b604051610050919061017c565b60405180910390f35b610073600480360381019061006e91906101c8565b610090565b6040516100819291906101f5565b60405180910390f35b60005481565b600080600183111561012c573073ffffffffffffffffffffffffffffffffffffffff1663b2041d216001856100c5919061024d565b6040518263ffffffff1660e01b81526004016100e1919061017c565b60408051808303816000875af11580156100ff573d6000803e3d6000fd5b505050506040513d601f19601f820116820180604052508101906101239190610296565b9150915061015e565b6001830361014b57828361014091906102d6565b60039150915061015e565b828361015791906102d6565b6004915091505b915091565b6000819050919050565b61017681610163565b82525050565b6000602082019050610191600083018461016d565b92915050565b600080fd5b6101a581610163565b81146101b057600080fd5b50565b6000813590506101c28161019c565b92915050565b6000602082840312156101de576101dd610197565b5b60006101ec848285016101b3565b91505092915050565b600060408201905061020a600083018561016d565b610217602083018461016d565b9392505050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052601160045260246000fd5b600061025882610163565b915061026383610163565b925082820390508181111561027b5761027a61021e565b5b92915050565b6000815190506102908161019c565b92915050565b600080604083850312156102ad576102ac610197565b5b60006102bb85828601610281565b92505060206102cc85828601610281565b9150509250929050565b60006102e182610163565b91506102ec83610163565b92508282019050808211156103045761030361021e565b5b9291505056fea2646970667358221220cd90d466f813134e4d8b2c517f7d7e99bd7d5b43e4ca6481b1a1d81be55ec4e064736f6c63430008190033

Then calling it with this data in a separate transaction:

0xb2041d210000000000000000000000000000000000000000000000000000000000000005

I was able to reproduce these results once on devnet, with the same strange ordering.