Adds /dev/block/by-name/<partition> symlinks

During uevent processing, some "by-name" symlinks will be created.
    /dev/block/<type>/<device>/by-name/<partition>

<type> can be: platform, pci or vbd.
<device> might be: soc.0/f9824900.sdhci, soc.0/f9824900.sdhci, etc.
<partition> might be: system, vendor, system_a, system_b, etc.

e.g., on a non-A/B device:
    /dev/block/platform/soc.0/f9824900.sdhci/by-name/system
    /dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor

On a A/B device:
    /dev/block/platform/soc/1da4000.ufshc/by-name/system_a
    /dev/block/platform/soc/1da4000.ufshc/by-name/system_b
    /dev/block/platform/soc/1da4000.ufshc/by-name/vendor_a
    /dev/block/platform/soc/1da4000.ufshc/by-name/vendor_b

However, those symlinks are "device-specific".

This change adds the "generic" symlinks in ueventd, in addition to
the existing symlinks, when the possible "boot devices" are specified
in device tree. e.g.,

    &firmware_android {
	compatible = "android,firmware";
	boot_devices ="soc/1da4000.ufshc,soc.0/f9824900.sdhci";
    }

The following symlinks will then be created on the aforementioned non-A/B
and A/B devices, respectively.

    /dev/block/by-name/system
    /dev/block/by-name/vendor

    /dev/block/by-name/system_a
    /dev/block/by-name/system_b
    /dev/block/by-name/vendor_a
    /dev/block/by-name/vendor_b

Note that both <type> and <device> are skipped in the newly create symlinks.
It assumes there is no more than one devices with the same <partition>,
which is the assumption of current first stage mount flow.

Finally, when 'boot_devices' in DT is absent, it fallbacks to extract
'boot_devices' from fstab settings. e.g., using 'soc/1da4000.ufshc',
'soc.0/f9824900.sdhci' for a fstab with the following content:

   /dev/block/platform/soc/1da4000.ufshc/by-name/system
   /dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor

Bug: 78613232
Test: adb shell ls /dev/block/by-name
Change-Id: Iec920b5a72409b6a2bdbeeb290f0a3acd2046b5d

0 files changed, 0 insertions, 0 deletions