Discard placeholder DMI serial numbers

[eriknordmark]

PENDING — do not merge yet. This is parked on the outcome of a wider design
discussion about easier device onboarding. Both commits stand on their own, but
the second one changes which SMBIOS field a device reports as its serial, and
that choice should be settled as part of that design rather than landed
piecemeal. Opened as a draft so the code and its rationale are reviewable in
the meantime.

Description

EVE reads its hardware serial number from the SMBIOS system serial number, which
firmware frequently leaves unprogrammed. An unprogrammed field is not empty — it
contains filler such as To be filled by O.E.M., Default string, an echo of
the field's own name (System Serial Number), or a counting pattern
(0123456789). Every unit of an affected model reports the same string, so a
controller that identifies a device by it cannot tell those units apart.

Before this PR only the single literal Not Specified was recognized, so every
other placeholder was reported verbatim and sent in the register request.

Two commits, separable:

1. pillar: discard placeholder DMI serial numbers — recognizes the
placeholder values, discards them from both the SMBIOS and the CPU/SoC source,
and reports an empty serial when neither carries a device-specific value. The
value set is the union of the placeholder lists maintained by eleven upstream
projects; the doc comment names each by repository, path and symbol so any entry
can be checked against its source.

2. pillar: fall back to the baseboard serial number — consults the SMBIOS
baseboard serial when the system serial is unusable, before the CPU/SoC serial.
Two cases motivate it. A board sold to an integrator frequently ships with the
system and chassis serials left as filler while the baseboard serial is the only
real value on the unit. And some vendors write the value printed on the outside
label into the baseboard field rather than the system field, telling customers to
try both — on those, the serial an operator reads off the label only becomes
visible once the baseboard field is consulted.

The source of the reported serial is now logged, and falling back past the system
serial is logged at notice level. That distinction is operational: no vendor
discloses a baseboard serial to a purchaser, so a serial sourced from it can
identify a device to a controller but cannot be pre-registered from the order
paperwork. An operator seeing a serial that does not match the label needs the
log line to know which field the device used.

Registration cannot regress, for two independent reasons. A controller that fails
to match the hardware serial retries with the soft serial, so consulting more
sources can only add matches. And an already-onboarded device does not
re-establish its identity by serial number on an EVE update: device-steps.sh
always runs getUuid and only adds selfRegister while an onboarding
certificate is still present in /config, and when selfRegister does not match,
client falls through to getUuid against the device certificate — logging
"getUUID succeeded; selfRegister no longer needed". So the changed serial affects
which devices can be onboarded from now on, not the identity of devices already
in a controller's inventory.

Related: #6346 (a cloned live image never gets a unique soft serial) covers the
other half of the same problem — this PR does not fix it.

PR dependencies

None.

How to test and validate this PR

Automated: go test ./hardware/... in pkg/pillar. TestIsDMIPlaceholder
separates serials observed on real hardware from firmware filler;
TestFirstUsableSerial exercises the source ordering, the skipping of
placeholders, and the empty result when the chain is exhausted.

Both tests were validated against the pre-change behavior: reverting the
detection produces 25 assertion failures while leaving the real-serial cases
green, and neutering the fallback fails 4 of its 6 cases.

On a device:

1. On hardware whose dmidecode -s system-serial-number returns a placeholder —
   0123456789 is common on Supermicro boards sold to integrators — confirm the
   reported serial is no longer that value. dmidecode -s baseboard-serial-number
   on the same unit typically shows the real serial, and that is what should now
   be reported.
2. Check the log for the source line: GetProductSerial: falling back to baseboard-serial-number, or ignoring placeholder system-serial-number "...".
3. On hardware with a properly programmed system serial, confirm the reported
   value is unchanged and the log records using system-serial-number.
4. Onboard a device whose system serial is a placeholder and whose soft serial is
   registered, and confirm registration still succeeds via the soft serial.

Changelog notes

EVE no longer reports firmware placeholder text such as "To be filled by
O.E.M." or "0123456789" as a device serial number, and falls back to the
baseboard serial number when the system serial number is unset or is a
placeholder. The source of the reported serial is recorded in the log.

PR Backports

• 17.0-stable: No, pending the onboarding design discussion noted above.
• 16.0-stable: No, pending the onboarding design discussion noted above.
• 14.5-stable: No, pending the onboarding design discussion noted above.
• 13.4-stable: No, pending the onboarding design discussion noted above.

Checklist

• I've provided a proper description
• I've added the proper documentation
• I've tested my PR on amd64 device
• I've tested my PR on arm64 device
• I've written the test verification instructions
• I've set the proper labels to this PR

Notes on the unchecked boxes:

• Documentation: docs/DEPLOYMENT.md describes the serial number as
  "semi-unique" but does not document the source chain. That doc update is
  deliberately deferred to the onboarding design discussion, since the chain may
  change.
• arm64: not tested on arm64 hardware. The CPU/SoC path is the ARM-relevant one
  and is unchanged in ordering, but it is now placeholder-filtered, which matters
  for SoCs that report an all-zero serial.
• Labels: left unset pending the design discussion; no stable label since no
  backport is proposed.

[codecov]

Codecov Report

❌ Patch coverage is 68.88889% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 25.02%. Comparing base (d69296f) to head (15d5cbc).
⚠️ Report is 6 commits behind head on master.

Files with missing lines	Patch %	Lines
pkg/pillar/hardware/model.go	68.88%	14 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6381      +/-   ##
==========================================
+ Coverage   24.65%   25.02%   +0.36%     
==========================================
  Files         516      526      +10     
  Lines       94177    95928    +1751     
==========================================
+ Hits        23222    24008     +786     
- Misses      69090    69872     +782     
- Partials     1865     2048     +183     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.