[17.0-stable] Surface how the vault was unlocked and report the key derivation

[eriknordmark]

Description

Backport of #6058 and #6455 to 17.0-stable.

Whether the vault was unsealed by the locally TPM-sealed key or by the
controller's escrowed key after a failed local unseal is not visible after the
fact: both end with the vault enabled, both log "successfully unsealed", and the
boot-time vaultmgr logs rotate out of the in-memory ring. Nor does anything say
whether the key is the TPM key alone or is still merged with the fixed constant
kept for vaults created before EVE 7.10.0, where half the key material is not
TPM-held. Both facts are decided on the device and never leave it, so neither is
visible across a fleet.

vaultmgr now records the unlock method at each unlock site and the derivation
mode when the vault config is read, carries both out on VaultStatus, and
zedagent puts them in info.VaultInfo. diag appends the unlock method to its
vault line and raises the level to WARNING for a controller-key or
wipe-and-recreate unlock. Both enums are pillar-native values cast to their
eve-api counterparts, pinned by a unit test so renumbering either side fails
instead of mislabelling a fleet report.

Three commits: #6058 cherry-picked with -x, a re-pin of pkg/pillar to the
eve-api revision carrying the new VaultInfo fields, and #6455's pillar change
cherry-picked with -x.

PR dependencies

None. The eve-api side (lf-edge/eve-api#157) is already merged; eve-api has no
stable branches, so the pin can only move forward on main and the regenerated
bindings also carry the API additions merged since this branch's previous pin,
none of which pillar reads here. Only pkg/pillar is re-pinned — the other
modules on this branch reference none of the new fields, and no Dockerfile
FROM hash changes as a result (make check-docker-hashes-consistency passes).

Adaptations

• This branch already carries the VaultTrimStatus work, which sits in exactly
  the places both commits touch. The two field sets are merged rather than one
  replacing the other, and ps/ucChan are not duplicated.
• pkg/pillar/docs/vaultmgr.md: Report vault unlock method and key derivation #6455's two doc additions are dropped. This
  branch's vaultmgr.md predates master's rewrite of it and has neither the
  data-at-rest bullet nor the VaultStatus field list they attach to.

How to test and validate this PR

In pkg/pillar: go test ./types/ ./cmd/diag/, which includes
TestVaultUnlockMethodToProto and TestVaultKeyDerivationToProto — these fail
if either enum is renumbered on either side of the cast. go build ./...,
go vet ./types/ ./cmd/vaultmgr/ ./cmd/zedagent/ ./cmd/diag/ and gofmt -l are
clean on this branch, as is make check-docker-hashes-consistency.

On a device, diag gains unlock:<method>, with the mismatching PCRs on a controller-key unlock on its vault line, and vaultmgr logs
vault <name> unlocked: method=<method> at each unlock site. A device whose
local TPM unseal succeeds reports tpm-local-sealed at INFO; one that fell back
to the controller's escrowed key reports controller-key at WARNING; one whose
vault was wiped and recreated reports recreated at WARNING; one without a TPM
reports no-tpm. The same values, plus the key derivation, reach the controller
in VaultInfo, where crossing HSMStatus == ENABLED with
key_derivation == UNSPECIFIED identifies devices that do not yet report it.

Changelog notes

The controller is now told how each device's vault was unlocked this boot and
whether its key is derived from the TPM alone or still mixes in the fixed
constant used before EVE 7.10.0. diag shows the unlock method on the device
and flags a controller-key or wipe-and-recreate unlock as a warning.

PR Backports

• 17.0-stable: This PR.
• 16.0-stable: Yes — see [16.0-stable] Surface how the vault was unlocked and report the key derivation #6492.
• 14.5-stable: Yes — see [14.5-stable] Surface how the vault was unlocked and report the key derivation #6493.
• 13.4-stable: Yes — see [13.4-stable] Surface how the vault was unlocked and report the key derivation #6494.

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
• I've added a reference link to the original PR
• PR's title follows the template

[codecov]

Codecov Report

❌ Patch coverage is 4.00000% with 96 lines in your changes missing coverage. Please review.
✅ Project coverage is 21.76%. Comparing base (e69cda3) to head (aac7d15).

Files with missing lines	Patch %	Lines
pkg/pillar/cmd/diag/diag.go	0.00%	39 Missing ⚠️
pkg/pillar/cmd/vaultmgr/vaultmgr.go	0.00%	35 Missing ⚠️
pkg/pillar/types/vaultmgrtypes.go	16.66%	20 Missing ⚠️
pkg/pillar/cmd/zedagent/reportinfo.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@               Coverage Diff               @@
##           17.0-stable    #6491      +/-   ##
===============================================
+ Coverage        21.38%   21.76%   +0.37%     
===============================================
  Files              500      510      +10     
  Lines            92650    94443    +1793     
===============================================
+ Hits             19813    20555     +742     
- Misses           71191    72061     +870     
- Partials          1646     1827     +181     

☔ 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.