https://github.com/dotnet/corefx/issues/42634 is caused by endless spin in System.Native when we fail to process routing table on first try. It was reported only on Catalina but that may be just timing difference.

It seems like existing code assumes that when sysctl() fails with ENOMEM, oldlenp would have new needed size. But that is not happening. According to 10.14 man page:

The information is copied into the buffer specified by oldp.  The size of the buffer is given by the location specified by oldlenp before the call, and that location gives the amount of data copied after
 a successful call and after a call that returns with the error code ENOMEM.  If the amount of data available is greater than the size of the buffer supplied, the call supplies as much data as fits in the
 buffer provided and returns with the error code ENOMEM.  If the old value is not desired, oldp and oldlenp should be set to NULL.

 The size of the available data can be determined by calling sysctl() with the NULL argument for oldp.  The size of the available data will be returned in the location pointed to by oldlenp.  For some
 operations, the amount of space may change often.  For these operations, the system attempts to round up so that the returned size is large enough for a call to return the data shortly thereafter.

I verified that if sysctl fails with ENOMEM and provided buffer, oldp has still old value e.g. amount written. I also verified that if we do another sysctl() call with buffer set to NULL, it provides back updated estimate. That however seems expensive as we need context switch to kernel and kernel will need to process routing table to get new estimate. Instead I decided to use same strategy as we use to dump tcp socket list and simply increase buffer 2x. That may temporarily need more memory but should be much cheeper on CPU processing.

cc: @ryanbrandenburg

fixes https://github.com/dotnet/corefx/issues/42634