runtime: .NET should no longer preemptively check for paths being too long

EDIT: See latest list of work items: https://github.com/dotnet/corefx/issues/8655#issuecomment-314969840

We’ve never been able to get this correct. Historically we’ve blocked using legitimate paths by trying to guess up front. Across all of the platforms we don’t have a rock solid way to know that a path will go over a particular API’s limit.

On Windows the historical “limit” has been MAX_PATH, but not all of the APIs enforce it. In addition, there is an ability to circumvent it for some APIs with extended DOS device syntax (\\?\). Even if we did have a list of every API we called and what it supported:

1. That API’s support could (and likely will) change
2. The real limits are based on complicated internal details that are difficult, if not impossible, to replicate (see DOS to NT: A Path’s Journey)
3. Lower level file systems (CDFS, UDF, NTFS, FAT16, ReFS, etc., etc.) impose their own limits which are nearly impossible to check with reparse points
4. Related to above we already get it wrong with path segments- not all file systems have a max of 255 characters

It is particularly problematic with normalization methods that we provide (Path.GetFullPath). Checking there can block legitimate uses with other API’s that don’t have the limits we are claiming are system wide.

PathTooLong should only throw from the actual platform invokes, which we already do.