device test for #4516 (WiFiClient leaking)

[d-a-v]

This test needs any TCP server and tries to find one on the gateway.
20 tcp connections are made, heap is measured.
Might be improvable (python tcp server, better measurement?)

Problem is heap does not depend on the sketch only, even if one tries to keep it straight.
See the success run, measurement must not stop at the bad moment.
Also we cannot presume how much is lost on each loop (64 here).

The same test is good too with 200 connections instead of 20, se we could make averages that would lower glitches.

Suggestions are welcome.

failed run (without fix):

10.43.1.254:80
heap: 44824
001 44760 -64
002 44696 -64
003 44632 -64
004 44568 -64
005 44504 -64
006 44440 -64
007 44376 -64
008 44312 -64
009 44248 -64
010 44184 -64
011 44120 -64
012 44056 -64
013 43992 -64
014 43928 -64
015 43864 -64
016 43800 -64
017 43736 -64
018 43672 -64
019 43608 -64
min heap: 22412
heap: 43608
loops: 20
heapLost: 1216

success run with fix (#4516):

10.43.1.254:80
heap: 44824
001 44824 0
002 44824 0
003 44824 0
004 44824 0
005 44824 0
006 44824 0
007 44824 0
008 44824 0
009 44824 0
010 44824 0
011 44824 0
012 44696 -128
013 44824 128
014 44824 0
015 44824 0
016 44696 -128
017 44824 128
018 44824 0
019 44824 0
min heap: 22412
heap: 44824
loops: 20
heapLost: 0

[d-a-v]

Robust now.
Counting the number of connections that do not change heap is simple and accurate.

failed run (without fix):

10.43.1.254:80
heap: 44824
001 44760 -64
002 44696 -64
003 44632 -64
004 44568 -64
005 44504 -64
006 44312 -192
007 44376 64
008 44312 -64
009 44248 -64
...
047 41816 -64
048 41752 -64
049 41816 64
050 41624 -192
heap: 41624
loops: 51
stable-loops: 0

success run with fix (#4516):

10.43.1.254:80
heap: 44824
001 44824 0
002 44824 0
003 44696 -128
004 44824 128
005 44824 0
006 44824 0
007 44824 0
008 44824 0
009 44824 0
010 44824 0
011 44824 0
012 44824 0
heap: 44824
loops: 12
stable-loops: 10