Zephyr: remove single thread support

[nashif]

Single thread support was added to reduce the footprint for use in mcuboot which did not require any multithreading or synchronisation.
Meanwhile we are adding subsystems and drivers into mcuboot that depend on multithreading features that makes single-thread support redundant.

Reduce complexity and provide just multi-threading support and focus on reducing footprint for all users.

[nvlsianpu]

Meanwhile we are adding subsystems and drivers into mcuboot that depend on multithreading features

@nashif Which one? Recently with @carlescufi we eliminated all multithreading dependencies in mcuboot@zephyr - maybe I don't know about something.

cc @utzig @d3zd3z

[Olivier-ProGlove]

Zephyr MCUBoot variant relies on Zephyr drivers. There is no guarantee Zephyr drivers do not use Zephyr kernel API that relies on multithreading support. see my pull-request for the discussion: https://github.com/zephyrproject-rtos/zephyr/pull/8368

We have three solutions:

• Use MULTITHREADING=y for MCUBoot Zephyr's backend - current direction followed by @nashif
• Disable Zephyr kernel API that are not suitable for MULTITHREADING=n
• Add a big warning next to MCUBoot Zephyr's backend to leave the developer to carefully review the Zephyr drivers, he/she uses.

[Olivier-ProGlove]

@nvlsianpu Funnily enough I had this issue today https://github.com/zephyrproject-rtos/zephyr/issues/10028 after rebasing on Zephyr v1.13...

[pfalcon]

Ok, so maybe mcuboot is better off being multithreaded. But why remove this cute feature? What complexity is being talked about? https://github.com/zephyrproject-rtos/zephyr/pull/10275/files hardly simplifies much.

[d3zd3z]

Also, just because some particular target may have a driver that needs multi threading, doesn't keep people from designing targets that are small, and don't have these requirements. There isn't just one configuration of MCUboot, and it needs to still be able to support very small targets, and work without threading support.

[pabigot]

See also ongoing discussion around https://github.com/zephyrproject-rtos/zephyr/issues/8393#issuecomment-662514878

[pabigot]

After reviewing the history and doing some testing I'm swayed by the point made somewhere that CONFIG_MULTITHREADING=n is essentially an untested configuration of Zephyr that may expose arbitrary problems, both in the existing code and in whatever gets merged in the future. I think this is a risky path to take, so I'm inclined to support removing the capability.

[carlescufi]

Closing in favor of #27415