nut-scanner reports each connection type separately, sanity-check suffers

[jimklimov]

Follows up from #1811 / #1810

As found during work on #1811 the nut-scanner parses each "nutdev" chains for each discovered type independently, not only for (parallelized, media/protocol-dependent) discovery, but also for final reporting, and the chains are freed just afterwards, e.g.:

  15.050071     [D1] SCANS DONE: display results
  15.050075     [D1] SCANS DONE: display results: USB
  15.050079     [D2] nutscan_display_ups_conf_with_sanity_check: USB
  15.050084     [D2] nutscan_display_ups_conf: USB
[nutdev1]
        driver = "usbhid-ups"
        port = "auto"
        vendorid = "0463"
        productid = "FFFF"
        product = "Ellipse ECO"
        serial = "000000000"
        vendor = "EATON"
        bus = "003"
        device = "002"
        ###NOTMATCHED-YET###bcdDevice = "0100"
  15.050118     [D2] nutscan_display_sanity_check: USB
  15.050123     [D2] nutscan_display_sanity_check_serial: USB
  15.050128     [D3] nutscan_display_sanity_check_serial: checking serial numbers for 1 device configuration(s)
  15.050132     [D3] nutscan_display_sanity_check_serial: new entry for serial '000000000'

# WARNING: all-same character "serial" with 9 copies of '0' (0x30) reported in some devices: nutdev1
  15.050141     [D1] SCANS DONE: free resources: USB

  15.050147     [D1] SCANS DONE: display results: SNMP
  15.050151     [D2] nutscan_display_ups_conf_with_sanity_check: <NULL>
  15.050155     [D2] nutscan_display_ups_conf: <NULL>
  15.050159     [D2] nutscan_display_sanity_check: <NULL>
  15.050163     [D2] nutscan_display_sanity_check_serial: <NULL>
  15.050166     [D1] SCANS DONE: free resources: SNMP

  15.050169     [D1] SCANS DONE: display results: XML/HTTP
  15.050172     [D2] nutscan_display_ups_conf_with_sanity_check: <NULL>
  15.050176     [D2] nutscan_display_ups_conf: <NULL>
  15.050179     [D2] nutscan_display_sanity_check: <NULL>
  15.050182     [D2] nutscan_display_sanity_check_serial: <NULL>
  15.050185     [D1] SCANS DONE: free resources: XML/HTTP

  15.050188     [D1] SCANS DONE: display results: NUT bus (old)
  15.050191     [D2] nutscan_display_ups_conf_with_sanity_check: <NULL>
  15.050195     [D2] nutscan_display_ups_conf: <NULL>
  15.050198     [D2] nutscan_display_sanity_check: <NULL>
  15.050201     [D2] nutscan_display_sanity_check_serial: <NULL>
  15.050204     [D1] SCANS DONE: free resources: NUT bus (old)

  15.050208     [D1] SCANS DONE: display results: NUT bus (avahi)
  15.050212     [D2] nutscan_display_ups_conf_with_sanity_check: <NULL>
  15.050216     [D2] nutscan_display_ups_conf: <NULL>
  15.050219     [D2] nutscan_display_sanity_check: <NULL>
  15.050222     [D2] nutscan_display_sanity_check_serial: <NULL>
  15.050225     [D1] SCANS DONE: free resources: NUT bus (avahi)

  15.050228     [D1] SCANS DONE: display results: IPMI
  15.050232     [D2] nutscan_display_ups_conf_with_sanity_check: <NULL>
  15.050235     [D2] nutscan_display_ups_conf: <NULL>
  15.050238     [D2] nutscan_display_sanity_check: <NULL>
  15.050241     [D2] nutscan_display_sanity_check_serial: <NULL>
  15.050244     [D1] SCANS DONE: free resources: IPMI

  15.050248     [D1] SCANS DONE: display results: SERIAL
  15.050251     [D2] nutscan_display_ups_conf_with_sanity_check: <NULL>
  15.050254     [D2] nutscan_display_ups_conf: <NULL>
  15.050257     [D2] nutscan_display_sanity_check: <NULL>
  15.050260     [D2] nutscan_display_sanity_check_serial: <NULL>
  15.050264     [D1] SCANS DONE: free resources: SERIAL

  15.050268     [D1] SCANS DONE: free common scanner resources
  15.050276     [D1] SCANS DONE: EXIT_SUCCESS

On one hand, since the "nutdev" strings are emitted by virtue of a static nutdev_num counter in nutscan_display_ups_conf(), the matching device naming in sanity-check methods becomes opportunistic (we do try to use same counter initially, but it may generally still depend on the order we run code or skip variants).

On another hand, we can not provide sanity-checks like "you have two drivers to monitor same device" (e.g. USB and SNMP, based on "serial number" and/or other data) which may be a configuration problem or not; perhaps if we make a multi-pathing driver eventually - its config should be proposed instead => #273

This issue proposes to explore changing the data and code structure to:

1. Concatenate the discovered device chains into one long list before emitting the configuration and running sanity-checks
2. Keep track of "nutdevX" names as another field in the same discovered-device structure (may be populated only after such concatenation, e.g. by same nutscan_display_ups_conf()) to have reliable and definitive naming for the current run

[jimklimov]

UPDATE: As part of changes in NUT v2.8.2 release, numerous issues and PRs for nut-scanner about more reliable device naming (and config reporting) were addressed (cca Jan-Mar 2024), e.g.

• nut-scanner: fix device-name collisions in generated conf #2247
• nut-scanner USB: disable some output results #2221
• Fix nut-scanner device naming in sanity-check reports #2317
• Fix nut-scanner caveats about USB optional fields and simulation file discovery #2336