Fix: NVRAM value lookup fails when IFR VarStore name differs from NVRAM variable

[InvertReality]

I was recently looking at the 'SystemConfig' store and noticed that every setting was returning NOT FOUND (example below)

I did a bit of research (thanks to --debug, --dump-var and --dump-ifr , these were a godsend to finding this issue)

I discovered that the IFR VarStore name differs from the NVRAM variable name - the IFR declares the store as "SystemConfig" but the variable in NVRAM is published as "Setup"/"Custom", so essentially the NVRAMap name check was rejecting every hit and returning None. Running --dump-var on the SystemConfig GUID returned four ACTIVE matches in NVRAM and the variable name on every match was (as stated above) "Setup" or "Custom" and not "SystemConfig" as expected.

Another annoyance is that the GUID is shared by five different VarStores (in my example):

SystemConfig, AdvanceConfig, H19BootConfig, BootConfig, and a smaller SystemConfig

My fix was when the name lookup returns None, fall back to matching on the GUID + size.

The NVRAM header already stores the DataSize of every variable, essentially - If the GUID matches and the DataSize matches (vs.size), it's the right variable. Matching on GUID + size ensures we get back the correct Store because the IFR tells us the exact size of the store we are looking for. The size is fixed and cannot change, even when the NVRAM variable name differs from the IFR VarStore name, which is handy for using it as a backup match check.

'Name lookup' always run first. The size fallback only triggers when the name doesn't match. Stores where the IFR name and NVRAM name already match i.e. AmdSetup are completely unaffected.

Heres an example with the fix: