Explicitly set module name in zephyr/module.yml

[gregshue]

Follow Zephyr v3.2.0 new recommendation to explicitly set module names to enable usage of ZEPHYR__MODULE_DIR by other modules.

Verification:

1. (Pass) west build -p always -b nrf52840dk_nrf52840 bootloader/mcuboot/boot/zephyr/
2. (Pass) ./zephyr/scripts/twister --testsuite-root zephyr/tests/subsys/dfu/
3. (Pass) ./zephyr/scripts/twister --testsuite-root zephyr/samples/subsys/mgmt/mcumgr/smp_svr/
4. (Pass) ./zephyr/scripts/twister --testsuite-root bootloader/mcuboot/boot/zephyr/

Fixes #1491

Signed-off-by: Gregory Shue gregory.shue@legrand.com

[tejlmand]

this is a very unfortunate PR.

While it is true that it's advised to give a Zephyr module a dedicated name, then it's still not mandatory to do so.
One reason for this not to be mandatory is because there exists use-cases where a project may be included multiple times in different revision.

MCUboot is one such use-case, as it is being used directly by Zephyr:
https://github.com/zephyrproject-rtos/zephyr/blob/fa57cd613b65975fe9a5c86e9a7f348adbee9de1/west.yml#L183-L185

but is also used by TF-M as secure bootloader:
https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/887798f6e67203e6a77059a86edf41bb136a3c0b/lib/ext/mcuboot/CMakeLists.txt#L23-L29

In cases where the TF-M specified MCUboot revision is fetched through the manifest, such as here:
https://github.com/nrfconnect/sdk-nrf/blob/2e5b8c955e5107dad30906ad2f96a017ada2a59f/west.yml#L124-L127

then the module names will collide because they are identical.

Having MCUboot included in the manifest for TF-M has previously been discussed, but this PR prevents such possibilities.

@d3zd3z FYI.

[gregshue]

@tejlmand Thank you for raising these use cases. If I follow you correctly this boils down to the following issues:

1. When multiple executables need to use the same version of MCUboot, who decides the version?
2. When multiple executables in the workspace need to use different versions of MCUboot, who controls the version in view?

AFAICT, the first case is independent of whether the module is explicitly or implicitly named. The second is really just needing a different manifest for different projects in the workspace (e.g., seven are built with ncs ecosystem, five are built with mainline Zephyr ecosystem).

I'm probably missing something. At this point I see no need for multiple versions of a module to be visible in the workspace at the same time. Guidance?