v.0.99: global id migration fix

[sploiselle]

#26556 had a bug in that it did not properly determine the final dependency order of all IDs.

The bug was caused by this line, which @guswynn describes on Slack:

this is because .rev hasI: DoubleEndedIterator requirement. The iterator returned by Filter is double-ended (because its build on top of a double-ended one), so it just reverses the whole stack. basically, .rev doesnt buffer the values and then reverse them after the filter.

This means we just need to try again, but with the right approach to determining the final dependency order.

In addition, to do this, we need to allow the catalog to boot, initially, with out-of-order dependencies, which means reverting 7d348b6

I've tested this extensively locally but we'll be able to ensure it works using the cloud upgrade tests.

Motivation

This PR fixes a recognized bug.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes:

[ParkMyCar]

Only took a cursory glance, let me know if you want a closer review!

[maddyblue]

LGTM.

Should the soft assert be a not soft assert?

[sploiselle]

@maddyblue Yeah––that is a good point and one I thought about for a while. One of the things I've been trying to do is avoid panicking envd unless things simply cannot work. In this case, logging the Sentry error seems like a good approach because it doesn't necessarily bring down the customer environment and––if somewhere else in the code goes, "whoa that doesn't work without the dependencies being in order," then they will panic and we have a breadcrumb to find explaining the upstream issue.

This strategy was actually working; we'd been receiving Sentry notifications about this bug. Unfortunately, we were "desensitized to the signal" because of #26966 as well as the testing team being spread pretty thin atm.

If you have a different opinion on the best strategy, I will gladly defer to whatever diff you envision––just sharing how/why I approached this as I did.