In worker threads, don't hold onto return object

[njsmith]

This is the core part of the loop that our worker threads currently run:

trio/trio/_core/_thread_cache.py

Lines 60 to 73 in 6b0a094

	while True:
	if self._worker_lock.acquire(timeout=IDLE_TIMEOUT):
	# We got a job
	fn, deliver = self._job
	self._job = None
	result = outcome.capture(fn)
	# Tell the cache that we're available to be assigned a new
	# job. We do this *before* calling 'deliver', so that if
	# 'deliver' triggers a new job, it can be assigned to us
	# instead of spawning a new thread.
	self._thread_cache._idle_workers[self] = None
	deliver(result)
	del fn
	del deliver

You can see that we currently explicitly del fn and del deliver. That's because these are two arbitrary user objects, and if we didn't delete them, then they would stick around until the worker thread is assigned some other job, which might be a long time and could pin an arbitrary amount of objects in memory until then.

However, we don't del result, even though that is also an arbitrary user object and has the exact same problem... whoops.

We could add del result, but I think there's a better option. Obviously, trying to manually del each object is error prone -- we messed it up :-).

The better option is to take the chunk of code that handles the job, and move it into its own function or method, that the main loop calls. That way, any temporary state we create while handling a job is automatically released as soon as the job is finished. Basically let the interpreter worry about putting the dels in for us, so we can't mess it up.