Copy stable/11@r303970 to releng/11.0 as part of the 11.0-RELEASE
cycle.

Prune svn:mergeinfo from the new branch, and rename it to RC1.

Update __FreeBSD_version.

Use the quarterly branch for the default FreeBSD.conf pkg(8) repo and
the dvd1.iso packages population.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Fix the dynamic VHD format to work with qemu. The size of the disk
is taken to match the geometry and only when the geometry is max'd
out, is the actual recorded size taken.

Note that qemu has the same logic for the fixed VHD format. However
that is known to conflict with Microsoft Azure, where the recorded
size of the image is what counts.

Pointed out by: gjb@

Microsoft Azure expects the creator OS to be "Wi2k" and not "FBSD".
The image is not accepted for provisioning otherwise. Bump the
VHD creator tool version and the version of mkimg to signify our
success in provisioning.

Note that this also imapcts the dynamic VHD images.

Tested by: gjb@

Microsoft Azure demands that fixed VHD images are a whole number
of megabytes. This is on top of having the image rounded to the
matching geometry of the image size.
By rounding up to the next MB after rounding to the geometry, we
lost idempotency. Subsequent calls to resize the image will keep
increasing the image size.

Tested by: gjb@

Handle the case in which ncyls is 0.
While here, update copyright.

For the fixed VHD format, round the raw image size to the next
multiple of the cylinder size. This is what qemu-img seems to
be doing. Make sure to handle boundary cases where increasing
the image size by 1 cyclinder's worth would also result in a
change of geometry.

Suffix the cookie constants with ULL to silence warnings from compilers
that try to treat them as 32-bit values.

Fix builds on older FreeBSD versions and/or non-FreeBSD machines:
don't use _Static_assert unconditionally.

Add support for the fixed image type. The fixed image is effectively
a raw image with a VHD footer appended. There's little value that I
can see to use the fixed image type, but in order to make VHD images
for use by Microsoft's Azure platform, they must be fixed VHD images.

Support has been added by refactoring the code to re-use common code
and by adding a second output format structure. To created fixed VHD
images, specify "vhdf" as the output format.

Add a bandaid to fix GCC build (on sparc64 et al).

Add image_data() for checking whether a sequence of blocks has data.
Use this for VHD and VMDK to avoid allocating space in the image
for empty sectors.

Note that this negatively affects performance because mkimg uses a
temporary file for the intermediate storage. When mkimg has better
internal book keeping, performance can be significantly improved.

Add VHD support to mkimg(1). VHD is used by Xen and Microsoft's Hyper-V
among others.

Add an undocumented option for unit testing (-y). When given, the image
will have UUIDs and timestamps synthesized in a way that gives identical
results across runs. As such, UUIDs stop being unique, globally or
otherwise.

VHD support requested by: gjb@

Use image_copyout_region() to write 2MB of user data interleaved with
the block's sector bitmap. This should complete the support, modulo
bug fixing.

Add vhd_geometry() to fill in the geometry in the footer. We respect
the command line arguments if possible, but otherwise implement the
algorithm from the specification.

Support unit testing:
o use mkimg_uuid() instead of uuidgen().
o Check unit_testing in vhd_timestamp() to synthesize a time.

Previous commit was premature in stating that we could test. The
file must have the footer at the end and we didn't write it yet.
With this commit we actually write the footer.
Let the testing begin.

Construct and write the BAT.
To allow testing of the code so far, scribble a bitmap before we write
the image. This won't work for images that need multiple blocks, because
each block starts with a sector bitmap, followed by 4096 sectors of user
data. But it works nicely for images that fit in a single block (and are
rounded to a block size.

With this commit, we can test if the Azura platform accepts our images.

o Avoid using strncpy(), as it will confuse Coverity. Use integrals for
cookies and creator information. Just as meaningless; more cryptic.
o Construct the dynamuc header and write it out.

In vhd_write(), construct the footer and write it out. Next in line
is the dynamic header. After that, the block allocation table and
the actual blocks. It's for the blocks we need some infrastructure
support, because each data block is preceeded by a bitmap that tells
whether a sector in that block has been written, etc. The point is
that we interleave metadata with data and we don't have good support
functions for writing chunks of the image yet.

Implement vhd_resize(): we round to a multiple of the block size,
which is 4096 sectors per block or 2M bytes per block.

Add structure definitions for headers with related constants .

Add stubbed vhd.c for VHD support.