crude hack in presets.cpp

[softhack007]

I just saw that preset.cpp contains a somewhat 'crude hack' - see below.

It might be dangerous:

• the observation that user code runs on core 1, while system events (like network requests) run on core 0 may not always be true.
• core allocation can be changed at compile time; try adding -DARDUINO_RUNNING_CORE=0 -DARDUINO_EVENT_RUNNING_CORE=1 in your platformio.ini
• there are ESP32 chips without second core - both"classic" ESP32 and some of the newer "-C3" and "-S2" variants sometimes have only one single core. On single core, the variable core will always have the value false (i.e. 0).

Please consider if there are other options to (more reliably) detect where a file request came from.

https://github.com/Aircoookie/WLED/blob/19c8b4fe2d0d86887d49abd5c965fd1d46502679/wled00/presets.cpp#L14-L24

[blazoncek]

The upcoming changes I proposed introduce a asynchronous preset loading which always happens within main loop().
Unfortunately this leads to all sorts of different problems (making some presets with HTTP API no longer work correctly and UI not getting a correct preset ID on return, etc).
If you want to test please use my fork, dev branch.

[softhack007]

In SR WLED, we found a solution by

1. using a patched version of Lorol LittleFS, which is more thread-safe (https://github.com/softhack007/LITTLEFS-threadsafe.git#master)

2. replacing the "coreID" checks with a check for task names:
   https://github.com/atuline/WLED/blob/153e29b927f2afaec4fcd96f4cbe2c71506eeab0/wled00/presets.cpp#L13-L31

Users feedback was very positive after these changes. No more "lost preset" problems seen.

[softhack007]

Solved in 0_14 branch by using new async presets implementation. Can be closed.