Some testing by @sp1 as mentioned on Slack confirms that the following disables the retries altogether:
LMIC_setTxData2(..., ..., ..., 1);
// Disable automatic retries when confirmed uplink is not acknowledged.
// ONLY DO THIS WHEN INDEED USING A CONFIRMED UPLINK.
LMIC.txCnt = TXCONF_ATTEMPTS;
Beware that erroneously doing this for unconfirmed uplinks, will make LMIC ignore regular downlinks. This is actually by design and even validated during LoRaWAN compliance testing:
So, as a result of messing with LMIC.txCnt, for unconfirmed uplinks LMIC.dataLen will always be zero in EV_TXCOMPLETE. (Tested with MCCI LMIC 3.2.0. For confirmed uplinks, both a bare ACK and a downlink that holds an ACK along with an application downlink, work fine with the above.)
Setting it to some lower value might limit it to, say, 2 retries yielding a total of 3 attempts:
// Limit to 2 retries, yielding a total of 3 attempts.
// ONLY DO THIS WHEN INDEED USING A CONFIRMED UPLINK.
LMIC.txCnt = TXCONF_ATTEMPTS - 2;
Peeking into the code suggests that this also works when LMiC delays the actual transmission due to duty cycle limitations. However, for OTAA the above needs that the node has already joined; if not joined yet then LMIC will invoke LMIC.txCnt = 0 after the successful join, before the actual packet is going to be transmitted, hence resetting the remaining attempts to 8. One might be able to circumvent that by explicitly starting the OTAA Join in the setup, by calling LMIC_startJoining() before invoking any LMIC_setTxData or LMIC_setTxData2. (See “Backgound” in Can LMIC 1.6 be set up to use a single channel and SF?)
Of course, all above implies you’re now relying on the internals of LMIC to never change…