First, there is no “connection”. Second, OTAA and ABP are only used to activate the device and, for OTAA, possibly get some network settings. Once activated, there is no difference between OTAA and ABP devices†. And they still don’t have “a connection” but will just transmit when they want, hoping one or more gateways will receive their transmission and forward it to TTN. This is general LoRaWAN, not specific for LMIC.
In a way, one could say that LMIC is OTAA-only: if you schedule a packet using LMIC_setTxData2 then when it’s time to transmit, LMIC will always first do an OTAA join if it has not been activated yet. That is: if it has no session keys yet. There is no choice: LMIC always does OTAA then, and at that point things fail if you did not program the OTAA details into the device.
To avoid that, one can manually invoke LMIC_setSession first. That, for example, is required for an OTAA device that already joined earlier, but for which the state is not kept in memory during deep sleep. (And then there’s more to restore than just the session secrets, most importantly the frame counters but much more; see How to persist LMIC OTAA parameters with an ESP32? - #12 by jofleck)
So, when one explicitly wants ABP rather than OTAA, then one can call LMIC_setSession before scheduling the first packet. This way LMIC also supports ABP.
I’m sure one can figure out from the LMIC internals if it last activated using OTAA or LMIC_setSession. But as you already know in your own code, the question would be: why?
† Well, except that an OTAA device might easily re-activate if ever needed, and then by design gets a clean state on the network. When resetting an ABP device then all sorts of state mismatch will happen between network and device, most notably the frame counters being reset in the device but not on the network. Go OTAA.