Fix header injection vulnerabilities

A number of vulnerabilities were found during JRA-16024 which expose JIRA to header injection attacks:

Note that different application server configurations may expose or hide the presence of a header injection vulnerability. Standalone tomcat is usually not vulnerable.

Tomcat 5.5.26 redirects all of the above to setHeader() which is implemented in the Coyote (HTTP) connector such that bytes in header values \r\n are translated to spaces. This is not specified behaviour but avoids header injection when using that connector.

Tomcat + Apache HTTPd with mod_jk configured and over https is known to not perform the Coyote header value translation making it entirely vulnerable to Header Injection.

Jetty 6.1.14 in a simple embedded deployment with the default HTTP connector URL encodes values in setCookie values but opens setContentType and sendRedirect to Header Injection.

Suspect Classes

ViewThumbnailServlet most likely has a hole. IF an image attachment contains a filename with the \r\n characters, when the thumbnail is viewed, this
filename will be supplied raw as part of the Content-Disposition header. The corresponding code in ViewAttachment URL encodes the value.

TrustedApplicationsFilter could be a possible Header Injection site since the data from the request headers is routed to the response headers. This relies on there being some way to encode the header separator (\r\n) into the request header. No such encoding mechanism has been found.

bugzillasearch.jsp is vulnerable, the id parameter is used in a header, it is also involved in an XSS bug raised [here|].

JiraWebActionSupport returnUrl support seems to be vulnerable. If this is correct, then this is a similar bug to SER-127