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

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

networkupstools / nut

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

2247

2221

2317

2336