Simplify the handle stuck in queued interface

[dstandish]

Proposed changes to #43520

This changes the signature of cleanup_stuck_queued_tasks such that it returns Iterable[TaskInstance] instead of List[str] (where the str is a repr).

What are the implications....

Old provider with new executor:

• we check what kind of object the executor is returning. if it is a string, then we know it's old executor version. in that case we just log to stdout of scheduler and move on.

New provider with old executor:

• New provider would be yielding TIs instead of strings. The executor would be expecting list of repr strings. The repr IN check would not find matches. Thus nothing would be logged. Nothing breaks but you don't have the log messages about stuck TIs. So this combination should be avoided and we might want to bump min version of provider. Or we could add backcompat code in the providers to yield the reprs in that case. That should work ok too.

[dstandish]

one reason i removed the "rescheduling" part is because at the point where you log this, you don't know that it's reschedulable -- you only know that further down.

[dstandish]

it's a scheduler setting not core, and more a retry than a reschedule

[dstandish]

the thing that still bothers me @dimberman is, it doesn't feel right that we defer to the executor and only conditionally log if it "cleans up" the ti. we have already observed that it is stuck in queued so why not log that?

i guess the problem is we are logging the wrong event. the event is not that it is "stuck in queued" (which is an unconditional observation) but rather that it was requeued. that's the thing that conditionally happens.