Curious about this, why don't we reuse this mechanism for getting notified about changes, instead of adding the notificationCenter notification?

For one because this was checking only when active subscriptions changed.
Now that I'm changing the cache invalidation to checking CustomerInfo changes we could.

However, this is used by #2007. Using a notification makes it a lot simpler so that we don't have to manually couple TrialOrIntroPriceEligibilityChecker to CustomerInfoManager. What do you think?

Bump @aboedo
I addressed your comments 10 days ago.

the part that I find a bit concerning is that we have 2 things updating from a change in customerInfo, but we don't have much control over the ordering.
if we're using this for cache invalidation, doesn't it mean that it's possible that you have a closure coming in from here that uses an outdated cache of intro eligibility values?

The 2 sources is a valid concern. I think they serve different purposes though.
The notification pattern is useful for 1-N notifications without strongly coupling types, and it simplifies the hierarchy. The current dependency injection approach is prone to retain cycles and leaks as exposed in the other PRs.

As for ordering, I'm not sure that's an issue in this case. Not sure what you mean exactly. #2007 won't recreate the eligibility, simply invalidate the cache for the next time it's requested.

Bump @aboedo.