Reticulate: Recover tests

[dfalbel]

This PR overrides the default post_handler_hook and pre_handler_hook in the IPyKernel instance, so that exceptions from executing it are not raised with exc_info=True.
Those hooks were added in ipython/ipykernel#49 to allow customizing the signal behaviors.
Later, they started being executed in a try context and exceptions: ipython/ipykernel#360
Their code hasn't changed in the last 10 years, so it seems safe to override them like this.

Addresses #10953

The problem we are trying to solve described in #10953 is that in Reticulate sessions on Linux, some execute requests hang, causing the kernel to be completely unresponsive.

I'm not entirely sure why this fix works, but here's the hypothesis:

• The kernel receives an execute_request.
• The shell thread starts processing it and runs the pre_handler_hook which fails in reticulate (because you can't signal from the main thread)
• This causes a log message to be written with self.log.debug("Unable to signal in pre_handler_hook:", exc_info=True)
• Log messages are written to an OutStream, which will eventually flush.
• Flushing needs to re-schedule to the IO thread and is a locking operation with a 10s timeout. This can cause hangs eg, we delay responding to rpc status messages, etc.

The hypothesis is that larger tracebacks, makes the IO thread queue larger, which makes more likely that flushing times out.

Release Notes

New Features

• N/A

Bug Fixes

• N/A

QA Notes

@:reticulate @:web

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical @:reticulate @:web

^{readme  valid tags}

[seeM]

Nice fix, looks like it was a tough one!

[midleman]

Oh wow! Nice to see this PR. If you don't mind I'm going to add the @:web tag as well and kick off again. Just to be doubly sure...

[midleman]

Awesome! Will keep an eye on how these tests perform over time since they used to give us so much trouble.