- fix for unescaped brackets in params values
[Issue #1217] Cutting the knot with respect to API compatibility
Build and run unit tests against the iOS 5.0 SDK to validate minimum deployment target compatibility
[Issue #1241] Fixing potential race condition in cancelConnection
Merge branch 'bracket-pull-request' of github.com:opentable/AFNetworking into opentable-bracket-pull-request

Conflicts:
	AFNetworking/AFHTTPClient.m
Fixing merge in 52ad3f838022b2bc0d5e7f897e695dc8bc0fc227
[Issue #887] [Issue #1096] Removing implementation of connection:needNewBodyStream:
[Issue #1288] Improving implementation of connection:didRecieveData: to handle case where stream -hasSpaceAvailable returns NO by polling. For in-memory buffers, this will almost never happen.

[Issue #1093] Handling stream errors in connection:didRecieveData:
[Issue #1093] Handling stream errors for AFMultipartBodyStream
[Issue #1288] Adding loop around write to ensure entire length of data is written
[Issue #1206] Fixing checks for network reachability flags over WWAN
Bumping version to 1.3.3
Revert "[Issue #1206] Fixing checks for network reachability flags over WWAN"

This reverts commit 71171423218973ec8bee04d3d262e4311cf80558.
Give a human readable Warning when SSL Pinning fails.

Encryption, SSL and Certificates are hard to gasp.
And generally errors like "The operation couldn’t be completed.
(NSURLErrorDomain error -1012.)" are hard to make sense of.

I subscribe to the theory that if you enable SSL Pinning
and it fails, something went horribly wrong
a) you misconfigured the thing, a certificate expired or
   some other developer screw up.
b) your application is unter attack.

Both secenarios warrant a clear and obvious message in the
log files. This breaks with the "no logging" approach in
AFURLConnectionOperation and maybe an `NSAssert` would
be better but if SSP pinning fails something fishy is going
on and we should leave some obvious evidence about this.
Assert that no impossible pinning configuration exists

If you use certificate pinning you MUST provide at least
one certificate/key file within the application bundle.
If you don't, you will not be able to preform any
successfull network requests.

I have been bitten several times by not correctly
including a Certificate/Key in the bundle and spend
far too much time debugging this.

This two assertations catch this programming error.
Not including a Certificate/Key in the bundle while
demanding pinning is obviously a programming error
and not a runtime issue.

Hope this helps a tiny bit to get more widespread
adoption of certificate pinning.
Merge pull request #1451 from mdornseif/pinningWarning_1.x

1.x: Give a human readable Warning when SSL Pinning fails.
Merge pull request #1450 from mdornseif/pinningNoKeyWarning_1.x

1.x: Assert that no impossible pinning configuration exists
Remove unused variable 'kAFStreamToStreamBufferSize'
Don't use NSUInteger as format argument, add explicit cast instead
Merge pull request #1764 from doo/ake-fix-warnings

Fix two warnings that show up recently