BUG: file leak in read_excel
I _think_ this 
closes #30031
closes #29514 
 we'll probably want to wait a few days to make it official.

To make the new test decorator useful in the CI we'll need to add psutil to the environment (unless someone knows of a stdlib way of doing the same check?)

One more note, the check in check_no_file_leaks depends on `__del__` having been called, which in turn depends on the gc.  I'm not sure, but that might induce another layer of flakiness.  If so, I think that can be fixed by calling `gc.collect()` before doing the `flist == flist2` check
LGTM - if this works! thanks for the fix! great. maybe keep rebasing a few times this to see if it fails. > maybe keep rebasing a few times this to see if it fails.

Seems like a more effective way of checking this against many runs would be to merge and see if the py36 failures go away? > > maybe keep rebasing a few times this to see if it fails.
> 
> Seems like a more effective way of checking this against many runs would be to merge and see if the py36 failures go away?

sure @jbrockmendel xref #47656: Does this miss a `gc.collect()` before the leak check? Some leaks will go away with a GC run. In #47656 there are a bunch of `boundmethod` objects that form a cycle with their originator class (`SAS7BDATReader`). That's plausible, but I'll need a lot more caffeine to say more than that.  An extra better-safe-than-sorry gc.collect call wouldn't be the end of the world.