Reduce the fixed 250ms ack delay

[Zlatin Balevsky]

See https://trac.i2p2.de/ticket/1939#comment:14 for background on how this was discovered.

I performed 5 test runs in the testnet with each value below with a 25MB file. It is interesting to see how up to a point reducing the value increases the speed.

ack delay(ms) | speeds (kb/s)
===================
300 | 150, 125, 119, 156, 166
250 | 169, 147, 142, 168, 179
200 | 192, 198, 214, 156, 198
150 | 179, 296, 332, 204, 212
100 | 166, 212, 222, 274, 196
50 | 88, 123, 76, 86, 250

I ran a t-test and there is less than 1.3% chance the difference between the 250ms and 150ms samples occurred by chance.

​https://www.statisticshowto.datasciencecentral.com/probability-and-statistics/t-test/
​https://help.libreoffice.org/Calc/Statistical_Functions_Part_Five#TTEST

It's hard to say to what extent this reflects the conditions in the live network, but I think it's worth considering a reduction in the ack delay.

[Zlatin Balevsky]

Some more data points if anyone wants to do better analysis:

250ms:
151, 137, 169, 150, 176, 150, 189, 198, 149, 170, 175, 259, 216, 151, 153

150ms:
183, 192, 244, 239, 227, 277, 252, 188, 254, 223, 259, 249, 201, 251, 246

[zzz]

Good research, no objection to 150.
As noted in the code comments, for loopback connections if the buffer gets overrun then we start choking, which I believe is what you're seeing with a delay of 50.
In 2ec35a4caf7e2622fd5aa9e8c4edc6c3aff9c80f to be 0.9.41-7