Standardize the way of navigating setup menu in tests and allow for exceptions

[philipandag]

The problem you're addressing (if any)

The tests traverse the setup menu by hardcoding where to enter, e.g. RTD001.001:

   (...)
   Power On
    ${setup_menu}=    Enter Setup Menu Tianocore And Return Construction
    ${dasharo_menu}=    Enter Dasharo System Features    ${setup_menu}
    ${usb_menu}=    Enter Dasharo Submenu    ${dasharo_menu}    USB Configuration
    Set Option State    ${usb_menu}    Enable USB stack    ${FALSE}
    (...)

Turns out that the structure of the setup menu will not always be the same. If the structure changes all the tests would need to be checked for errors in the traversing. It has already happened once #601 (comment)

The setup menu options are also accessed using the Get UEFI Option and Set UEFI Option keywords, which might create confusion.

Describe the solution you'd like

The paths to all the points of interest in the setup menu should be defined in one place, the way of accessing them should be standardized.

Where is the value to a user, and who might that user be?

Testers, more robust tests, less issues and broken test cases when something in the setup menu changes.

Describe alternatives you've considered

No response

Additional context

An effort to do this might have already been done with the addition of getoptionpath dictinonary to the lib/bios/menus.py library. The library does not support the fact that different releases of Dasharo could have different names:

The option is called Enable COM0 Serial Console Redirection in Dasharo v1.1.4, and Enable Serial Port Console Redirection in v1.1.3. The getoptionpath dictionary from lib/bios/menus.py does not take this into account:

(...)
 "SerialRedirection": [
     "Dasharo System Features",
     "Serial Port Configuration",
     "Enable Serial Port Console Redirection",
 ],
(...)

Some ideas from the discussion in #601:

The main question here is how much of variance in the paths is accepted in the future? Will it only be alternative names of single options? What about the names of submenus? Maybe whole paths will be changed, or the options will be moved between existing menus?

If the menus.py library was used everywhere menus are traversed then exceptions in names could be easy to fix. I'd imagine the library could just keep alternative paths to the options and the alternatives could be tried one by one.

So instead of a list of steps:

    "SerialRedirection": [
        "Dasharo System Features",
        "Serial Port Configuration",
        "Enable Serial Port Console Redirection",  # Enable COM0 Serial Console Redirection??
    ],

A tree could be used.

    "SerialRedirection": [
        "Dasharo System Features": [
            "Serial Port Configuration": [
                "Enable Serial Port Console Redirection",
                "Enable COM0 Serial Console Redirection"
            ]
        ]
    ],

Also there's the option to define paths and menu option names in the menus as config variables, which would need creating and maintaining a whole lot of them. There are 15 paths, 7 submenus and 16 option names defined in menus.py. And there already are too many variables in the configs to remember.

${SETUP_SUBMENU_DASHARO_SYSTEM_FEATURES}=    "Dasharo System Features"
${SETUP_SUBMENU_SERIAL_PORT_CONFIG}=    "Serial Port Configuration"
${SETUP_OPTION_SERIAL_PORT_REDIRECTION}=    "Enable COM0 Serial Console Redirection"
@{OPTION_PATH_SERIAL_PORT_REDIRECTION}=
...    ${SETUP_SUBMENU_DASHARO_SYSTEM_FEATURES}
...    ${SETUP_SUBMENU_SERIAL_PORT_CONFIG}
...    ${SETUP_OPTION_SERIAL_PORT_REDIRECTION}

This way though any future change in the menus structure would be easily fixable on per-platform basis and there would be no need to dynamically look around for where the options are located, which could take a lot of time depending on the amount of possible alternative paths.