[v0.10] fix: CloseWait with buffered data potentially causing a dead-lock

[Ddystopia]

When broker sends FIN and socket enters CLOSE_WAIT, tcp socket return PipeClosed to the minimq and connection_died is set to true. But what happens next? If minimq is used as sync library, poll will be called next and client.update() will notice that connection died and issue TcpDisconnected event, triggering reconnect to the broker. But with async code, every poll is weighted and has a reason. smoltcp will not issue any wake anymore because the socket is in CLOSE_WAIT state (nothing can arrive to it), thus until the application tries to write something to mqtt, minimq will not get polled, reconnect to the broker will not happen.

Thus, the change is simple - before exiting from poll, call update once more in case connection broke and initiate reconnect. smoltcp or other implementation of embedded_hal::TcpClientStack will handle the rest.

Alternatives: async user can make several poll of minimq but this is extremely fragile and doesn't scale, not even talking about the waste.

Additionally, I made a simple refactor, as no one will expect if self.socket_was_closed() to mutate something. I split it into a getter and a reset method.

[jordens]

This failed CI. Could you investigate. I'm happy to keep a release-0.10 stable sync branch around for these fixes.

async comes with the larger redesign in #173

[Ddystopia]

@jordens it doesn't seem to be an issue with the code, but with the runner infrastructure.