explicit close() of DML iterator returning values leaves partly executed statement

This is not too dissimiar to MB-50828, but it entails explicitly closing the iterator half way.

Create a bucket default and insert a few documents:

INSERT INTO default VALUES(uuid(),

{"f1": 1}

);
INSERT INTO default VALUES(uuid(),

{"f1": 1}

);
INSERT INTO default VALUES(uuid(),

{"f1": 1}

);
INSERT INTO default VALUES(uuid(),

{"f1": 1}

);
INSERT INTO default VALUES(uuid(),

{"f1": 1}

);
INSERT INTO default VALUES(uuid(),

{"f1": 1}

);
....(do it a few hundred times)

create the following javascript function:

function somedml()

{ var q = UPDATE default SET f1 = 2; q.close() }

create and execute the UDF:

CREATE FUNCTION somedml() LANGUAGE javascript AS "somedml" AT "test";
EXECUTE FUNCTION dml();

This function updates default, and q.close is a noop..
Now try with a RETURNING clause:

function somedml()

{ var q = UPDATE default SET f1 = 2 RETURNING f1; q.close() }

Here, by the time q.close() is called, some documents will have been updates, some will be pending awaiting being pulled from the iterator, and the close() cancels the iterator.

I think the moral here is clear - much like cancelling left over requests and the end of the function should complete pending DML rather than cancelling it, an explicit q.close() should check mutations, and if it is > 0 should complete rather than cancel.