nrf: remove critical section around sd_app_evt_wait()

[dhalbert]

• Fixes nrf52840 builds not working #5201.

#5182 added a critical section around sd_app_evt_wait(), which prevents USB from coming up (and perhaps other things).

circuitpython/ports/nrf/supervisor/port.c

Lines 367 to 372 in fdfcaf0

	uint8_t is_nested_critical_region;
	sd_nvic_critical_region_enter(&is_nested_critical_region);
	if (!background_callback_pending()) {
	sd_app_evt_wait();
	}
	sd_nvic_critical_region_exit(is_nested_critical_region);

This removes that critical section, which was not present before.

Other uses I see of sd_app_evt_wait() don't do anything special (no critical sections, etc.)

@tannewt I'm not sure if this the most correct fix, based on what your intention was, which was to shut off as many interrupts as possible and do the equivalent of a WFI. The documentation says the following.

uint32_t sd_app_evt_wait(void)

Waits for an application event.

An application event is either an application interrupt or a pended interrupt when the interrupt is disabled.

When the application waits for an application event by calling this function, an interrupt that is enabled will be taken immediately on pending since this function will wait in thread mode, then the execution will return in the application's main thread.

In order to wake up from disabled interrupts, the SEVONPEND flag has to be set in the Cortex-M MCU's System Control Register (SCR), CMSIS_SCB. In that case, when a disabled interrupt gets pended, this function will return to the application's main thread.

Note
The application must ensure that the pended flag is cleared using sd_nvic_ClearPendingIRQ in order to sleep using this function. This is only necessary for disabled interrupts, as the interrupt handler will clear the pending flag automatically for enabled interrupts.
If an application interrupt has happened since the last time sd_app_evt_wait was called this function will return immediately and not go to sleep. This is to avoid race conditions that can occur when a flag is updated in the interrupt handler and processed in the main loop.
Postcondition
An application interrupt has happened or a interrupt pending flag is set.

[jerryneedell]

confirmed that build fdfcaf0 also failed the same way on an nRF52840 Bluefruit Sense:
Compiled with this PR -- both the bluefruit sense and the raytac dongle boot normally.

[tannewt]

I'm fine just removing it. My intent was to prevent a background race like the other case but obviously it wasn't correct. :-) We can keep it in mind if we see issues w/it.