fix: gracefully handle unsettable keys during automocking

[simon-abbott]

Sometimes while automocking we will encounter a property that, for some unknown reason, throws an error when you try to define it. Unfortunately I can't figure out why it errors, so instead I have opted to quietly skip these unsettable properties. If that becomes a problem in the future this can be revisited, but I don't forsee it being an issue since these keys are mostly deeply internal prototype stuff that 99.999% of people don't even know exists, let alone want to mock. Plus, if you really need to have this behavior you can always use __mocks__ or just shim it inline yourself.

Fixes #1671

[sheremet-va]

It feels like we are going into a trap 🤔

deeply internal prototype stuff that 99.999% of people don't even know exists

If we don't copy internal stuff, how can public stuff access it?

[simon-abbott]

If we don't copy internal stuff, how can public stuff access it?

It doesn't need to. The output of the automocking process is an entirely new object with all methods stubbed out. Not spied on, completely overwritten. Therefore the internal implementation of these top-level APIs are irrelevant, since they won't be used anyway, and thus the deeper layers are also irrelevant since they won't actually be used by anything.

I'm sure there will be at least one person at some point who will actually need some of those items mocked, but as I said they can always just make their own mock via the __mocks__ folder and set it up however they need.

[simon-abbott]

It seems that the macos and windows tests timed out, but I don't know why and I can't reproduce it locally. Any ideas?