Allow for deleting connection in an unexpected state

[terencecho]

What

When a temporal workflow is in an unexpected state, there is no way to delete a connection unless you interact with temporal directly. This PR will make it so that the deletion occurs even if the temporal state is in an unexpected state and addresses issue #11214.

How

If the temporal workflow is in an unexpected state, we spin up a new workflow and send a signal to delete the connection.

Tests

In addition to unit tests, this was tested locally by terminating a temporal workflow with the command docker run --rm -it --entrypoint tctl --env TEMPORAL_CLI_ADDRESS=host.docker.internal:7233 temporalio/admin-tools:1.14.0 wf terminate --wid <workflow_id> and then attempting to delete the connection through the UI.

[terencecho]

The unit test should probably all live in the temporal client test file, but for some reason the test kept on hanging when I tried to port the test to that file, so I kept them in the connection manager workflow test file for now. fyi @benmoriceau

[benmoriceau]

It looks good overall.

I don't think that we need the tests that are in the ConnectionManagerWorkflowTest class. The fact that we are instantiating the Temporal client in it is a warning to me, we should just check that we call the start with signal or just the signal method base on the existence of the workflow in the temporal client.

Does it sound right to you?

[terencecho]

@benmoriceau that works for me. That was my original plan, but i realize that test didn't actually track/check the state of anything. I was going to include both, but I ran into some null pointer exceptions with signalRequest.add(connectionManagerWorkflow::run, input); since connectionManagerWorkflow is mocked.

I think i can figure it out and put it up soon.

[benmoriceau]

LGTM: Could we think about an AcceptanceTest for this as well?

[terencecho]

I just saw the comment about the AcceptanceTest after merging. I can work on one in a different diff.