Fix flaky datetime test

[davidhewitt]

I think I realised there's a simple workaround for #720

The release pool unsoundness in #756 is all related to reference types - &PyAny, &PyDict.

So I think swapping them out for PyObject and Py<PyDict>, which have different drop semantics, should stop this test biting us all the time on CI.

(Fixes #720)

[kngwyu]

Thank you, but how about locking other threads? As an experiment, I opened #862.

[pganssle]

Assuming it works, I like two things about #862's approach over this one:

1. It has minimal changes to the underlying test structure.
2. When Release pool unsoundness #756 is fixed, we can simply remove the locks and the datetime test will act as something of a regression test.

That said, I'm not sure that I spent a huge amount of time thinking about whether to use a borrow or an owned reference here, so unless I was much more thoughtful about this than I remember being "minimal changes" amounts to "keeping the arbitrary thing I did when I made this instead of switching to another arbitrary, valid choice."

With regards to point 2 - when we fix #756 we should probably write a dedicated regression test with a much higher chance of triggering the bug, so again this is really only a weak preference.

I think we should probably decide between the two options (assuming they both work) based on what we would do if we didn't have release pool soundness issues. I sorta think we've been moving towards the &PyDict / &PyAny recommendation whenever possible (and thus we should go with #862), but I haven't been able to keep up with all the changes y'all have been making lately, so maybe that's out-of-date information?

[davidhewitt]

Cool, I'll close this one. It looks like #862 works (all CI is green).

We can always resurrect this PR later if we still have trouble after #862.