Based on #485

Closes #480.

The issue is not addressed directly as suggested; rationale:

FROST is not a robust protocol, meaning participants can always prevent a signing sessions from succeeding. For this reason, we don't actively try to prevent participants from being able to abort sessions; they can do that in a myriad of different ways like sending a invalid encrypted message. That being said, we did add a message limit check on the server to mitigate memory exhaustion (since otherwise the length would only be checked when someone receives and decrypts a message). We also added session cleanup in case of error for coordinator and DKG starter, to avoid having aborted sessions lingering in case of error during the protocol.