Revert "[FIXED JENKINS-17451] "projects tied to slave" shows unrelated maven module jobs. shows TopLevelItem only."

This reverts commit 3a6de84f.
(Regressed JENKINS-15666.)
Conflicts:

	changelog.html

[FIXED JENKINS-17451] "projects tied to slave" shows unrelated maven module jobs. shows TopLevelItem only.

Root cause seems to be broken serial form of FingerprintAction, probably caused by lazy loading.

Also provide proper overrides of ParameterValue.getShortDescription, rather than delegating to toString.

Don't break Windows XP, fall back gracefully to no-op.

[FIXED JENKINS-7970] JUnit result archiver should only fail builds if there are really no results - i.e. also no skipped tests.

Instead, it shows a small 'v' icon to the right that needs to be clicked
to open a context menu.

[FIXED JENKINS-17330] FilePath.installIfNecessaryFrom should avoid routing download over remoting channel.

[FIXED JENKINS-7291] Permit flyweight tasks to run on master even when it has zero configured executors.

Always adding Computer for master as a fallback

The original proposed fix for JENKINS-7291 creates a Computer object
transitively. This seems unwise as it violates the design of Computer
as stated in the javadoc, and for example we can end up creating two
Computers for the master.

I think a better fix is to create a Computer for the master all the
time, even if there's no executors configured. The discrimination in
Queue.makeBuildable would ensure that such phantom Computer is only used
as a last resort (statistically speaking).

I've also tweaked executors.jelly a bit. I simplified it somewhat
based on the idea that "if there's only one computer to show, the
context is likely making it obvious".

(I must be missing the intricacy in the current code.)

Originally developed in a branch at
2c5b57fcc1f39ed39057254e802f4183db5aa0dc then squashed for clarity.

[FIXED JENKINS-17331] PerJobLocalRepositoryLocator should prefer the MavenModuleSetBuild.workspace for single-module builds.

[FIXED JENKINS-13154] AnnotationMapper bug was causing massive lock contention when saving fingerprints.

Fixed the throughput problem between master/slave communication.
This fix contains two independent problems.

One was in the remoting. During a large sustained data transfer
(such as artifact archiving and large test reports), the way we
were doing flow control and ACK-ing were penalizing us badly.
I improved the flow control algorithm in remoting 1.23, and also
increased advertised window size so that the transfer can saturate
available bandwidth even when a latency is large. (And unless
the reader side is excessivesly slow, this shouldn't increase
any memory consumption.)

The other fix was in trilead-ssh2, which is our SSH client
implementation used by ssh-slaves plugin. The buffer size for flow
control was too small. I improved the way buffering is done to reduce
the memory footprint when the reader closely follows the writer, then I
increased the advertised window size. Again, this shouldn't increase
memory consumption (in fact it'll likely actually reduce them) unless
the reader end gets abandoned.

On my simulated latency-injected network, the sustained transfer rate is
now on par with scp. We win for smaller files because of the TCP slow
start penality that scp would incur, and we lose a bit as files get
larger due to additional framing overhead.

If you have manually extracted slave.jar and placed them on slaves, you
need to update them to 2.23 to see the performance benefits.

[FIXED JENKINS-17177] wrong build result in post build steps after failed pre build step in maven project

Made the in-flight build survive the reload from the disk.

Report 100 recent builds in the JSON API, including in-progress builds.

Not reporting all the builds since this would nullify the lazy loading
effect. Will introduce a pagenation API that supports retrieval.

Remember the permalink target as symlink (or simple text file) so that
looking that up doesn't cause the walk of the build history.
I think this is more in line with our general preference of making
$JENKINS_HOME useful (than trying to persist cache into a blackbox.)

Having a general purpose in-memory cache could be useful, so I'll see if
I can add that, too, in a way that allows someone to plug different
backend.