(enhancement) testing: improve build times

In #752 we talked about a few possible ways to avoid extraneous builds and general integration test time.

While rebasing the tests for Fedora 27, I continued tinkering with two of these ideas to see what their workflow would look like and generate ballpark test times. I don't have review-able code at the moment, but wanted to talk a bit more the general ideas:

Reuse an existing kpatch-build cache from ~/.kpatch. To do this, I added a kpatch-build command line option --cache which accepted two actions: build and copy. Before building a series of kpatches, the --cache build option downloads, builds the specified targets, and then stops. (It is not compatible with any input patches on the command line.) The cachedir can now be renamed .kpatch.copy, backed up, whatever. Then when building kpatch modules with --cache copy option, kpatch-build will rsync --archive --delete .kpatch.copy .kpatch instead of (re)downloading and (re)building the original kernel.

Rsync is nice here as it will only restore what changed between builds. Therefore, reusing the kpatch cache works best when few objects are updated. However, if a patch causes an entire tree rebuild, then a subsequent --cache copy rsync could take more than a few moments.
Add object target specification(s) to the integration patch files. Obviously we need to know what targets will be affected by the patch, so this needs to be used with care. To test the idea, I added the target name(s) to the top of the patch file description and fed those as kpatch-build --target options.

Here are some very preliminary numbers. Not all of the Fedora 27 test patches build yet, so the final numbers might be a little different. However I think the data is still interesting to see:

VM
==
qemu with kvm enabled
Memory 4096 MB
CPUs 6

==> out.VM <==
real    1770m34.007s
==> out.VM.cache <==
real    450m31.223s
==> out.VM.cache.target <==
real    307m18.664s

Beaker machine
==============
Model Name      Intel(R) Xeon(R) CPU X3470 @ 2.93GHz
Memory  32768 MB
CPUs 8

==> out.beaker <==
real    295m58.502s
==> out.beaker.cache <==
real    115m2.115s
==> out.beaker.cache.target <==
real    36m30.839s

These two optimizations led to full integration tests of only 13-17% of their original wall times. (The numbers may change a bit once all of the tests build successfully for Fedora 27.)

The only other low-hanging integration test time improvement might be to push meminfo-cmdline-rebuild-SLOW.patch to the end of the patch list. That would help us eliminate an extra, full-tree rsync restoration as no patches would follow in its wake. Beyond that, I think better hardware (CPUs and SSD storage) might be the best bang for your buck.

dynup / kpatch

(enhancement) testing: improve build times #771