pytest: Fix flaky test_closing_id test

[cdecker]

It simply wasn't waiting for us to register the peer before attempting to open a
connection. Moved into a separate test to be able rerun multiple times.

[ZmnSCPxj]

I wonder if this is good solution, though. If we use an automated system (i.e. a program that manages channels for you), and it decides to channel to a completely new peer, then the automated program would have to look into our c-lightning logs? It seems better if an automated system could connect and the fundchannel as soon as connect returns.

[rustyrussell]

In this case, I'm pretty sure the problem is that l1 has it closed, but not l2 yet. That's not a real problem, AFAICT, just a test artifact.

[ZmnSCPxj]

But it seems to imply that the sequence close connect fundchannel is unsafe for automated programs. One way this may be relevant is for example if a user makes a program that ensures a channel with a particular node gets refilled when it is depleted (e.g. the end user is a frequent customer of a merchant, for example). A simple way to do that, if the user has onchain funds, is precisely the close connect fundchannel sequence in the test.

[cdecker]

We can check locally that the connection was closed, but not remotely, so there is little we can do but retry.