Adding sys/socket.h constants for iOS/Mac, particularly for SO_SOCKET options

[drewcrawford]

This is probably more broadly applicable than these two platforms
(since it's part of the bsd4.4 standard) but that's outside my problem domain today.
If this goes well, I may submit Linux/64 support in a separate PR.

Reviewers should take a look at http://www.opensource.apple.com/source/xnu/xnu-792.17.14/bsd/sys/socket.h?txt
which defines constants for OSX. iOS uses the same header.

I release this patch under the MIT license.

[alexcrichton]

I think we may want to hold off on adding these until they're added for all platforms perhaps? Otherwise it may just be unfortunate to go to use them only to find that it only works on OSX :(

[drewcrawford]

Shouldn't the person in that situation submit a patch?

I would be surprised if there is a single person who can be sufficiently motivated to land this feature across all the supported configurations (and there are a ton in that file). Whereas, this PR is an existence proof that faced with this problem, someone will port it to platforms they need.

If you accept this PR, it means that every time I port my software to a new platform you'll see a PR to introduce these constants on more configurations, since that's a necessary step. (There are 2 implemented already, and a third is looming.) Contrariwise, if you reject it, I'll fix it at the project level, where platform additions can't flow freely into Rust.

This whole module is unstable anyway. It is not as if there's a stability guarantee that we would break by offering these APIs.

[vhbit]

@alexcrichton I think the proper way to handle this is to ask @dhuseby @semarie and @wg if they're interested in checking and exposing Bitrig/OpenBSD/FreeBSD specific flags, so all platforms move forward instead stopping one because of others.

@drewcrawford can you also and SO_NOSIGPIPE, it might be very often used on OS X/iOS.

[wg]

I checked FreeBSD 10.1 and verified that the values are identical there. Given that rust already has a bsd44 module and these are part of that standard it seems reasonable to add.

[semarie]

under OpenBSD -current the values are the same too (http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/sys/socket.h?rev=1.87&content-type=text/x-cvsweb-markup).

[semarie]

I checked for bitrig too (https://github.com/bitrig/bitrig/blob/master/sys/sys/socket.h) and it is the same too (@dhuseby please correct me if necessary).

(please note that under openbsd or bitrig, some additionnals options exists)

[alexcrichton]

@drewcrawford

I would be surprised if there is a single person who can be sufficiently motivated to land this feature across all the supported configurations (and there are a ton in that file).

I agree, but we have a number of tier one platforms that I would expect to all have support landed simultaneously.

This whole module is unstable anyway. It is not as if there's a stability guarantee that we would break by offering these APIs.

I agree, but it doesn't mean that this crate is the wild west! This crate is also only unstable in the distribution. It's reexported as stable.

[drewcrawford]

We've reached an impasse. I'm withdrawing to fix at the project level.