[reconfigurator] only clear the "will remove mupdate override" field if inventory is up-to-date

[sunshowers]

In #10392, we found while progressing along the MUPdate recovery state machine (RFD 556), duelling Nexuses might trample over each other based on stale inventory.

The specific reproduction is covered in the added reconfigurator-cli test, but to recap: Let's say there are two inventory collections, C1 and C2. C1 was collected right before the MUPdate, and C2 right after. Then, the failure happens if:

• Nexus 1 reads C2 and starts processing the MUPdate override, creating a blueprint B1.
• Nexus 2 has C1 cached, and creates a blueprint B2 with parent B1 but based on collection C1.
• In C1, the mupdate override is not present, so Nexus 2 believes (based on this outdated collection) that more progress has been made along the MUPdate recovery state machine.

The fix in this PR is to use the Sled Agent generation number stored in the parent blueprint as an indicator. If the Sled Agent generation gathered from inventory is older than that, then that is a sign that inventory is stale, and we shouldn't clear the "will remove mupdate override" field as a result.

We're hoping to cherry-pick this PR onto the r19 release branch. There is a very similar bug around setting the "will remove mupdate override" field as well. We believe the downsides of that bug are not as bad (i.e. the planner doesn't end up along a path which makes things worse), so we're currently not planning to pick that for 19.3. (We would like to get this bug fixed for release 20 though -- expect a PR for it soon.)

[davepacheco]

I've not reviewed the test output changes but the test changes and code changes look good to me. A second set of eyes would be good.

[davepacheco]

nit, take it or leave it: I generally frame this sort of thing without reference to the past... as in: "This test verifies that when resolving a MUPdate, the system correctly avoids resolving images when the inventory is stale."

[sunshowers]

Changed this to not refer to the bug but rather to the correct behavior:

# This test verifies that when resolving a MUPdate, the planner does not clear
# the "will remove mupdate override" field from a sled's blueprint based on stale
# inventory -- specifically, an inventory collection that occurred before
# the sled was MUPdated, so the mupdate override UUID isn't visible in it.

[sunshowers]

Tested this on berlin and the happy path appears to work well. The race condition is a bit hard to set up in a live system but we have reproduced it in the simulator (and this PR includes a test).