Preserve in-progress builds when reloading a job.
Because in-flight builds tend to update the state a lot, with this
change we refrain from reloading those builds from the disk.

This should be acceptable since we are primarily reloading a job, and
reloading of builds are secondary.

All top-level jobs show up in search, as opposed to just jobs in the
current view or in the primary view.

This reverts commit ebc6af72.

The actual meat of the change is in remoting.

I couldn't quite find one place to do this, so it's spread apart
somewhat.

I should have known better than reusing the version number. Apparently
the issue isn't just in Maven.

Stack trace:

org.jvnet.hudson.reactor.ReactorException: java.lang.IllegalAccessError: tried to access method hudson.security.SecurityRealm.findBean(Ljava/lang/Class;Lorg/springframework/context/ApplicationContext;)Ljava/lang/Object; from class hudson.security.LDAPSecurityRealm$LDAPUserDetailsService
  at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246)
  at jenkins.InitReactorRunner.run(InitReactorRunner.java:43)
  at jenkins.model.Jenkins.executeReactor(Jenkins.java:885)
  at jenkins.model.Jenkins.<init>(Jenkins.java:790)
  at hudson.model.Hudson.<init>(Hudson.java:81)
  at hudson.model.Hudson.<init>(Hudson.java:77)
  at hudson.WebAppMain$2.run(WebAppMain.java:217)
Caused by: java.lang.IllegalAccessError: tried to access method hudson.security.SecurityRealm.findBean(Ljava/lang/Class;Lorg/springframework/context/ApplicationContext;)Ljava/lang/Object; from class hudson.security.LDAPSecurityRealm$LDAPUserDetailsService
  at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.<init>(LDAPSecurityRealm.java:419)
  at hudson.security.LDAPSecurityRealm.createSecurityComponents(LDAPSecurityRealm.java:369)
  at hudson.security.SecurityRealm.getSecurityComponents(SecurityRealm.java:398)
  at hudson.security.HudsonFilter.reset(HudsonFilter.java:134)
  at jenkins.model.Jenkins.setSecurityRealm(Jenkins.java:1960)
  at jenkins.model.Jenkins$17.run(Jenkins.java:2524)
  at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
  at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
  at jenkins.model.Jenkins$7.runTask(Jenkins.java:874)
  at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
  at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
  at java.lang.Thread.run(Thread.java:680)

When managing instances with lots of jobs, the size of the view
configuration screen becomes huge because there is one line per job on
the instance.

Going beyond this requires CSS animation.

... since they didn't go to RC.

Previously, the presence of the xpath parameter suppressed the tree
parameter processing. This change fixes that so that the tree parameter
can be used for building small DOM, then XPath to manipulate the data
further.

Added test whether the currently checked slave computer actually can take the buildable item before flagging it as needed (avoids powering up and connecting to slaves for jobs they can't build).

It uses Diffie Hellman to come up with one-time session key, then have
the server sign this session key to allow the client to verify that
there's no man in the middle.

Until now, Jenkins.overallNodeProvisioner was tracking an inconsistent
pair of numbers. On one hand, it was tracking all the executors in the
system, but then it was also only tracking the # of free-roaming
label-unassigned jobs as the queue length.

So if all your slaves are set with Node.Mode.EXCLUSIVE and you have some
free-roaming jobs, then it'll never tickle NodePrivisioner.

In other words, the # of executors weren't reflecting the actual # of
executors that can execute what's counted as the queue length.

See the problem report at
https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-dev/bUwGEgOwv4Q

To fix this, I introduced another LoadStatistics that only counts
the # of executors that can execute free-roaming jobs, and # of
free-roaming jobs as the queue length. In this way, two pairs of numbers
are consistent.

This now allows us to use overallLoadStatistics for really the entire
system, including all executors and the total queue length. This is
primarily for administrators to see the resource utilization, and it is
not useful for NodeProvisioner input because it's mixing too many
different things.

The semantics change in OverallLoadStatistics.queueLength allows us to
deprecate its totalQueueLength field.

Fall back in non-JNA case wasn't working.