Adds circuit breaker when a task depends on itself

[desertaxle]

Adds a circuit breaker to raise when a task depends on itself which would otherwise cause a flow to hang indefinitely.

Closes #13874

Example

This flow sneakily has a task that depends on itself by updating an array in place:

from prefect import flow, task

@task
def say_hello(name):
    return f"Hello {name}!"

@flow
def my_flow():
    greeting_queue = []
    for i in range(2):
        if greeting_queue:
            wait_for = greeting_queue
        else:
            wait_for = []
        future = say_hello.submit(name=f"Person {i}", wait_for=wait_for)
        greeting_queue.append(future)
    
    for fut in greeting_queue:
        print(fut.result())

Running this flow with this PR will raise an error like this:

ValueError: Discovered a task depending on itself. Raising to avoid a deadlock. Please inspect the inputs and dependencies of say_hello.

Checklist

• This pull request references any related issue by including "closes <link to issue>"
  • If no issue exists and your change is not a small fix, please create an issue first.
• If this pull request adds new functionality, it includes unit tests that cover the changes
• This pull request includes a label categorizing the change e.g. maintenance, fix, feature, enhancement, docs.

For documentation changes:

• This pull request includes redirect settings in mint.json for files that are removed or renamed.

For new functions or classes in the Python SDK:

• This pull request includes helpful docstrings.
• If a new Python file was added, this pull request contains a stub page in the Python SDK docs and an entry in docs/mint.json navigation.

[chrisguidry]

Hmm, so the only way this can happen is if the caller changes the wait_for iterable after submitting the task. If we just make sure to make our own copy of wait_for, doesn't this problem go away?

[zangell44]

@desertaxle pointed out copying could cause memory issues. Maybe better to start simple and copy if we need to later?

[chrisguidry]

It wouldn't be a copy of the futures, just a copy of the iterable the caller gave us so that it's kind of "causally locked in" at that point (I'm just thinking literally wait_for = list(wait_for). I can't help but think there are other classes of bugs lurking if we let this list of futures be mutable after it's passed to the engine.

[desertaxle]

This also happens if futures are passed in parameters which can be deeply nested and would require a deepcopy to prevent subsequent modification from causing deadlocks. This probably won't happen often, so I'd rather raise in the unlikely chance this happens then incur a memory penalty in all other cases.