This code change is not consensus change, it is a utxo selection improvement.
It was tested prior to the Bible rules existence.
I hope that enhancing iguana during S4 is not forbidden, can you clarify about how to test code improvements/changes without breaking Bible rules?

This code change was discussed on discord with blackjok3r who said that it will fix one problem of this loop but the utxo selection loop needs a complete rewrite.

I had a bug on the main Notary Node (NN) but it didn't happen on the 3P NN on KMD.
If there is only one "iguana" UTXO and no other UTXO (*), no notarization happens and the following error happens:
no (%s -> %s) utxo: need to fund address.(%s) or wait for splitfund to confirm\n

(*) Such case can be encountered if the node is running out of assetchain balance and there is only one "iguana" UTXO left. it can also happens if playing with distant coin split and/or advanced use of wallet filters.

In such a case, the loop inside dpow_haveutxo will have n = cJSON_GetArraySize(unspents) = 1 because listunspent returns only one UTXO. As j variable is initialized at 0 before the loop and incremented at the beginning of the loop, j = 1 at the first iteration of the loop so j = n and the loop will exit. By moving the j incrementation at the end of the loop, it will execute the code within the loop if there is only one UTXO.

To test/analyse:

• add more logs and analyze iguana TV on main NN and 3P NN.

To test:

• Test with different coinsplit scripts,
• Test with distant coinsplit (e.g. with https://github.com/DeckerSU/komodo_scripts/blob/master/split_nn_sapling.sh) with/without wallet filters
• Test on main NN and 3P NN in different situations (no coin left, only one big utxo not splitted, same tests without sapling (OOT)).

Changelog for NN operators:
The number of the chosen UTXO will be decreased by 1, meaning the UTXO "numbering" in the log will start at UTXO 0 instead of starting from UTXO 1:
[%s] : chosen = %d out of %d loop.(%d)\n