Observe PurchaseHandler when owned externally

[jamesrb1]

Josh kindly fixed a problem while I was away where the purchase handler would get clobbered when the paywall was re-rendered. This PR restores avoiding having one struct owned by two @StateObjects at the same time.

[joshdholtz]

@jamesrb1 I think this looks good!

Does this still work with the overlay use case from the #4034?

Also, was there an example app use case where this fix was needed? Like where we observed some weird behavior? 🤔 Just want to make sure for documentation purposes incase we come across this again the in the future 😇

[jamesrb1]

Does this still work with the #4034 (comment) from the #4034?

Yes!

Screen.Recording.2024-07-26.at.11.33.47.AM.mov

Also, was there an example app use case where this fix was needed? Like where we observed some weird behavior? 🤔 Just want to make sure for documentation purposes incase we come across this again the in the future 😇

No, I've observed no ill-behavior from having one object referenced by two @StateObject properties. Everything I've read says one thing should own it, everything else should observe it. If there are zero @StateObject references, you risk unexpected behaviour and crashes. But I have not seen anything that addresses the case of having multiple @StateObjects, but since that goes against the expected usage, I think the only safe way to consider this is that it's undefined behavior. (If the "second" view that owns it as a @StateObject is destroyed, does that cause the object to be destroyed too, when something else is still owning it? Or does this use a reference counting setup where it would still be OK? I don't know, and I don't know if it's defined anywhere so what it does could change in the future.)