Disable optimization under full AOT. Fix bug #3682
Fix default SecurityManager properties to false (they should not be reached unless there's a bug, but they should be right)
Get better linker results when doing full-aot wrt the cryptographic stack
Redirect, by default, the Console.* and Console.Error.* output to NSLog
[Mono.Data.Sqlite] Fix a MonoTouch memory leak

Ensure SQLite3's GCHandle is freed when Close is called instead of Dispose.
Also make SQLiteConnection's Dispose call SQlite3's Dispose to ensure we free
the GCHandle in all cases.
Up the default max persistent connections to 10 for monotouch, and warn when we use more.
NetworkStream: Bring ReceiveTimeout, SendTimeout, Close to MOBILE profile
mobile/System.dll: Add BindingList<T>
Add some defensive exceptions to WebConnectionStream to try to track down #6329
Add some defensive exceptions to WebConnectionStream to try to track down #6329
Fix the mobile profile build of System.Core.dll.
Avoid using PredicateOf<T>.Always since it does not work with full-aot. Fix bug #682757...
Avoid multiple potential full-AOT failures with LINQ Enumerable. Fix bug #3285
Add workaround to make LINQ 4 Objects order by work under full-aot.
Use Function<T>:Identity instead of an inline lambda. Fixes 3627.
Fix Aes to behave correctly on MonoTouch wrt CryptoConfig (default creation) and fix it's FeedbackSize (for CFB)
Fix mobile profile build of System.dll
Fix #6349: Do not use KQueue on Darwin, as their kernel behaves differently than BSD

Introduce a new define that determines whether we can use kqueue for the threadpool,
and keep the old check for kqueue, in case we need to use it in the future for something
else.

From Gonzalo's notes:

I could not reproduce the problem at all on FreeBSD, but it happened
immediately on the Mac. And when it happened, I could never kill the
process (tried kill from outside and another thread with
Environment.Exit() but no luck). This led me to believe that it was an
OS problem. Both asynchronous operations work fine when they are the
only asynchronous operation on the socket (I turned the other into
synch). When read and writes are asychronous kqueue() changes the
event we are waiting for to be read/write. That is usually not a
problem, but in this particular case, it looked like 2 separate
threads were trying to do the same thing (one for read and one for
write). I tried a simple spin lock per file-descriptor to no avail. I
also tried a fat lock and again no luck. Then I found this:
http://lists.apple.com/archives/darwin-dev/2011/Jun/msg00016.html and
then remembered that back in 2006, when I first tried a patch to
support kqueue(), Geoff found a similar problem to this one (yeah,
what the fuck, Steve!). The problem has not surfaced earlier because
most people that use sockets know how to do it. Setting up read and
write asynch. calls at the same time is not something that pros do,
but...

Solutions?

1. Provide a way to disable kqueue at runtime for cases like this (can
we set the MONO_DISABLE_AIO environment variable in an iOS mono
program? Just Environment.SetEnvironmentVariable before the first use
of sockets/threadpool should work.

2. Disable kqueue by default. The benefits of things like epoll and
kqueue are negligible, really, unless people are dealing with several
hundreds of sockets (~500 and above) and the default poll based
implementation is ok for most applications (xsp would suffer a lot of
contention under load, but xsp uses asynch ops the right way :).
Update mcs/class/Novell.Directory.Ldap/Novell.Directory.Ldap.Rfc2251/RfcFilter.cs

This fixes bug 8278 (https://bugzilla.xamarin.com/show_bug.cgi?id=8278)
[Mono.Options] Add support for hidden options (which are not written in WriteOptionDescriptions).