CI: azure timeouts
Based on the logging in #43611, in both timeout cases, the last test `gw0` ran was before the hypothesis test in `test_parse_dates` (this is a giant test - 56 parameterizations, hypothesis does 100 examples by default).

Not sure why this would be the cause, couldn't find any issues about it that might explain a deadlock or something like that, but maybe this will help? Regardless of fixing timeouts, it makes sense for these to be slow

Maybe something similar to https://github.com/HypothesisWorks/hypothesis/issues/2340? Hmm this didn't work - new guess - the logging seems to stop around parser tests - maybe the fact that we use the same parser object across tests can cause deadlock (or issue is some mutation is happening?) We're at ~5 in a row on azure not timing out. Will keep running azure, but this is ready for review from my side. Summary of changes:
1. Mark hypothesis tests as slow
2. For parser fixtures, ensure we generate new objects instead of sharing them
3. skip pyarrow tests which can deadlock, xref #43650
(EDIT: just noticed more timeout cases on deadlock in #43611. Another option might be to just replace all `pyarrow` xfails with skips) > Mark hypothesis tests as slow

is there some option that can set on hypthosesis instead? the point of these tests is to find holes in our tests, which are almost all fast, so this just remove this entirely (which maybe ok). but then we should just do that. > is there some option that can set on hypthosesis instead? the point of these tests is to find holes in our tests, which are almost all fast, so this just remove this entirely (which maybe ok). but then we should just do that.

We could set fewer examples to run (but at some point that defeats the purpose of `hypothesis`). I thought on running on `slow` was a good compromise since it will still run on some builds, just fewer. 

Regardless, the important change here is skipping `pyarrow` for the `hypothesis` parse_dates test - will just remove the slow markers for now since it turned out `pyarrow` was the cause of the timeout, not the `hypothesis` tests sometimes running extremely slowly kk lgtm. ping when ready to merge (or just go ahead) note that I think we are seeing something similar on 1.3.4, but we didn't merge the pyarrow csv reader so prob something else. > note that I think we are seeing something similar on 1.3.4, but we didn't merge the pyarrow csv reader so prob something else.

Good to know - certainly possible there are other potential timeout-causing issues unrelated to pyarrow. Will keep running azure pipelines on #43611 to see if anything else comes up. This should at least make timeouts less frequently hopefully thanks @mzeitlin11 nice improvement here. Yeah let's keep an eye on 1.3.4