Common DFU partition enumeration API

[de-nordic]

Problem description

Zephyr supports several DFU methods (mcumgr, USB) and the support will increase probably.
The problem is that all of these methods use direct access to flash_map.h macros to decide what should be target partition/flash area for DFU and for that purpose define own macros or functions and naming conventions, for example:
mcumgr uses img_mgmt_find_best_area_id to select best partition and directly uses FLASH_AREA_ID to access it;
code relaying on mcuboot_priv.h uses definitions of FLASH_AREA_IMAGE_PRIMARY/SECONDARY to address partition the app is running from and update candidate; code that is defined in flash_img.c provided another set of macros and naming for the same task.

Above may lead to situations where code from different units would give different identifiers, problem which I have already faced while working on Direct-XIP within mcumgr (apache/mynewt-mcumgr#110)

There is also problem that application, due to configuration, may be more restrictive regarding the DFU target flash area, which modules like mcumgr may not be aware of in their own selection process.

Related or influenced by:

• Expand USB DFU to include more partitions Expand USB DFU to include more partitions #32135
• usb: dfu: rework of dfu class implementation usb: dfu: rework of dfu class implementation #30562 , usb: dfu: rework of dfu class implementation #30562 (comment)
• Use img_mgmt_find_best_area_id to select upload slot instead of FLASH_AREA_ID Use img_mgmt_find_best_area_id to select upload slot instead of FLASH_AREA_ID apache/mynewt-mcumgr#110
• dfu: mcuboot: Automatic primary/secondary image slot assignment dfu: mcuboot: Automatic primary/secondary image slot assignment #31715

Proposed change

My proposal is that Zephyr should provide DFU API that would allow to get information on currently active partition, the one the application is running from, and enumerate all allowed DFU partitions. Such single point of information would ease development and limit problems where different DFU services

Fr example following functions could be added, the naming is just proposal:

int dfu_get_active_partition() -- get ID of partition the application is running from
int dfu_enum_target_partition(int prev_id) -- enumerate through list of DFU allowed partitions.
int dfu_restrict_targets() -- allow to register function that will be called by dfu_enum_target_partition to filter out partition basing on internal logic; this should allow application to remove partitions it would not allow to dfu from.

[de-nordic]

It does not seem that resolving the issue makes any sense: the mcuboot and mcumgr are very much hardcoded to use two images anyway.