MDEV-41154: Report an error when the engine fails in ha_rnd_pos

[valbok]

DELETE skips the row without reporting anything when error is returned by handler::ha_rnd_pos()

Report every error except the two that genuinely mean "the row is not there
any more".

[FooBarrior]

And so it seems, an invariant "c" holds, though I added it as a seemingly valid, but a comic case :)

ha_tina, representing engine=CSV, only returns HA_ERR_END_OF_FILE for all the not-found cases. It doesn't have all the rich and diverse in-statement failure analysis, as other engines have. It never marks records "deleted", but deletes the record straight out of csv on every operation.

On the rnd_pos side, it receives a file offset. If previous operations deleted enough records, then the pre-saved offset may point...

At this point, fellows, I went to investigate further. If every delete_row shifts the records in file, and position holds a file offset, then wrong records may be deleted.

I came across this test: it deletes v=3 instead of the requested v=2:

CREATE TABLE t1 (v INT NOT NULL) ENGINE=CSV;
INSERT INTO t1 VALUES (1),(2),(3);
DELETE FROM a1, a3 USING t1 AS a1 JOIN t1 AS a3 WHERE a1.v=2 AND a3.v=1;
--echo # asked to remove v=1 and v=2, so v=3 must survive
SELECT * FROM t1 ORDER BY v;
DROP TABLE t1;

So rewriting in-between delete_row's and pre-collecting the positions to delete in a later pass is wrong.
But then, as soon as this is fixed, EOF won't be returned for ha_tina.

And so the result is "b": HA_ERR_END_OF_FILE cannot happen, but in a correct program :) in fact, we have it erroneously.

I think the following are the three alternatives, and only one holds:
a) HA_ERR_KEY_NOT_FOUND means not only that a key was deleted, but also generally not found;
b) HA_ERR_END_OF_FILE cannot happen;
c) HA_ERR_END_OF_FILE also means 'key was deleted'.