aggregated tProxy sends multiple `OpenExtendedMiningChannel` messages if clients connect too fast

[plebhash]

while writing Integration Tests for #156 I noticed that if I connected many minerd processes to tProxy (in aggregated mode) in a short period of time, it would send multiple OpenExtendedMiningChannel messages upstream

that should not be the case, as aggregated tProxy must open one single Extended Channel with the upstream connection

[GitGab19]

IIRC this is very similar to something I discussed with @Shourya742 some months ago when we were refactoring JDC.

I remember he considered this scenario (where multiple clients connect almost simultaneously) for JDC, so I guess the fix to this problem could be to handle it in a similar way to how we do in JDC.

cc @Shourya742

[Shourya742]

IIRC this is very similar to something I discussed with @Shourya742 some months ago when we were refactoring JDC.

I remember he considered this scenario (where multiple clients connect almost simultaneously) for JDC, so I guess the fix to this problem could be to handle it in a similar way to how we do in JDC.

cc @Shourya742

We do handle such scenario with caution in JDC, we can implement something very similar for tproxy.