Fix for tracked properties updating when using m3 native properties

[igorT]

The fix in #1376 was not correct. In order to properly entangle we need to be doing receiver.get but to protect against re-entrance in production, we need to manually keep track of the key being accessed.

[github-actions]

Performance Report for b010003

Scenario - materializing-lots: ⚠️ Performance regressed

⚠️ duration
phase estimated regression +101ms [53ms to 147ms] OR +1.06% [0.55% to 1.53%]
☑️ Phase [navigationStart] => [start-loading]
phase no difference [-3ms to 8ms]
⚠️ Phase [start-loading] => [pushed-payload]
phase estimated regression +63ms [37ms to 90ms] OR +1.4% [0.81% to 2%]
⚠️ Phase [pushed-payload] => [end-loading]
phase estimated regression +33ms [4ms to 60ms] OR +0.72% [0.08% to 1.32%]
☑️ Phase [end-loading] => [Test End]
phase no difference [-1ms to 1ms]

Scenario - materializing-small: ☑️ Performance is stable

☑️ duration
phase no difference [-6ms to 6ms]
☑️ Phase [navigationStart] => [start-loading]
phase no difference [-6ms to 4ms]
☑️ Phase [start-loading] => [pushed-payload]
phase no difference [-1ms to 2ms]
☑️ Phase [pushed-payload] => [end-loading]
phase no difference [-1ms to 2ms]
☑️ Phase [end-loading] => [Test End]
phase no difference [-1ms to 1ms]

Scenario - rendering: ☑️ Performance is stable

☑️ duration
phase no difference [-10ms to 9ms]
☑️ Phase [navigationStart] => [start-loading]
phase no difference [-2ms to 5ms]
⚠️ Phase [start-loading] => [pushed-payload]
phase estimated regression +2ms [0ms to 3ms] OR +2.07% [0.49% to 3.81%]
☑️ Phase [pushed-payload] => [end-loading]
phase no difference [-1ms to 0ms]
☑️ Phase [end-loading] => [Test End]
phase no difference [-9ms to 5ms]

[rwjblue]

Given the explanation in the comments, I think there is probably a more straight forward solution for us.

Do we think (with the new tests added) that all of the cases that we care about are handled?

[igorT]

Do we think (with the new tests added) that all of the cases that we care about are handled
I am not aware of any, do any come to mind?

[rwjblue]

Chatted a bit with @igorT about this (and my concerns in the prior comment). I think this is fine for now (with the tweak to use try/finally instead of relying on the nested access to reset), but we should work to refactor away from all of this.

The path forward is basically to migrate to using @glimmer/tracking/primitives/storage (which allows us to remove the need for Ember.get in the proxy handler's get hook, by ensuring that our own tags are property consumed/entangled) via the https://github.com/ember-polyfills/ember-tracked-storage-polyfill. Once we do that then we can make our proxy return undefined for both unknownProperty and setUknownProperty.

Those changes should likely be follow on work after this lands.