Fix Authorization header format validation to match RFC HTTP header specifications

[anomal]

According to RFC 2616, HTTP header values may have leading and trailing whitespace.

This fix may or may not address the 401 Unauthorized response in signalapp/Signal-iOS#5114 . (I do not own a Mac to be able to run iOS app version 3.9.0 in Xcode Simulator in debug mode, in order to reproduce the issue.) Either way, HTTP clients may implement the Authorization header values according to the RFC spec with leading or trailing whitespace.

Please comment on signalapp/Signal-iOS#5114 if/when this fix is deployed in production. An important Signal contact of mine cannot access years of Signal messages on their old iPhone that can only run iOS 10, which is only supported up to app version 3.9.0. These messages contain important data such as passwords to accounts, photos, and messages to reconstruct a sequence of events that occurred in the past.

[anomal]

Note that people often write HTTP headers in the following format:

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

In other words, there is a space after the colon, which is equivalent to a space before the header value.

RFC 2616 4.2 even mentions that the header value preceded by a single space is preferred:

The field value MAY be preceded by any amount of LWS, though a single SP is preferred.

[ehrenkret-signal]

I believe the HttpParser in the framework library strips these leading or trailing spaces out before ever reaching this point.

Do you have any evidence that the framework is not removing these leading or trailing spaces?