If a resource with 'Set-Cookie' header is cached (either by intermediary
like HTTP proxy and reverse proxy, or by the browser), it'll cause
identity swap / session mix-up as discussed in this ticket.

I suspect this was caused by HttpSessionContextIntegrationFilter2, which
is the only code path that attempts to create a session when a request
to a static resource is made.

So I'm disabling the creation of session in
HttpSessionContextIntegrationFilter2. This in turn requires that we
have sessions already created when the authentication was successful and
people need to login (or else the login will have no effect.)

We already do so in layout.jelly, so any request that renders a Jenkins
page would have a session, but I've also added it in
AuthenticationProcessingFilter2, which ensures that a successful login
does have a session.

Clean up FilePath. Extract one method out and ensure closing of input stream after copy

Fixes JENKINS-13649

[FIXES JENKINS-13649] As FilePath(FilePath,String) expects multi-segment relative paths, we should ensure that the multiple segments are using the correct separator character for the remote OS

we shouldn't change the definition of it.

Instead, I'm creating a new tag.

... to fix a possible race condition.

[JENKINS-13536] I think the proper thing to do is to use the Accept header, not the Content-Type header.

When a client uses the buildWithParameters API and request a json output, return the job definition as a json string instead of doing a redirect on the job page.