Simpler func for SimpleObjectPool

[AnthonySteele]

Summarise the changes this Pull Request makes.

Simpler func for SimpleObjectPool

For the SimpleObjectPool constructor:

• The constructor func can be Func<T>, we don't use the other param at all
• the constructor func is IMHO a more important param than an initial size, so should come first
• initial size has a default of zero

Please include a reference to a GitHub issue if appropriate.

[AnthonySteele]

Timer test CorrectDurationForStatInAsyncFunction is failing in travis, but it Works On My Machine.

[AnthonySteele]

todo in a later PR: SimpleObjectPool<T> is only ever used as a SimpleObjectPool<Socket> - is the generic necessary?

ConnectedSocketPool is a wrapper of SimpleObjectPool<Socket>, which means that it's more complex, each operation is forwarded, incurring a tiny extra delay. Fold these classes together?

[martincostello]

We can make this internal now too.

[AnthonySteele]

Good point, done

[martincostello]

And yes you're right, the generic is also redundant now too.

[AnthonySteele]

I plan to make a later PR to fold SimpleObjectPool into ConnectedSocketPool as this is the only place where it is used. It will be simpler, and might remove some small run-time overhead - the indirection might or might not be optimised out.

I don't think that there are better options than this; as far as I know, there is no suitable generic pool class in the framework, and we are already doing something very close to this example