Initialize all the name services we need

- A long time ago in a far away commit, "somebody" had this less than
  brilliant idea that calling gethostbyname() loads all the required
  name service libraries (commit 39b75d24cfe50e65ca940cc5466beb03c801d033).
  This is of course only true if hosts db happens to use the same
  database as passwd and group... which often is the case, but by
  no means guaranteed or always the case.
- Add an explicit initializer for rpmug to force loading the name service
  libraries early in initialization so we dont need to worry about going
  chroot later on. Of course, the "host" name service configuration might
  not actually make sense for the chroot, but this commit doesn't make
  that any worse than it already was.
- Backported from commit abbf4897db217b4977b4c21eb09929c797ee015d
Use git index in %autosetup (RhBug:1059285)

- Without --index in apply, any file additions will not be committed and
  in case the patch contains *only* file addition the macro can fail
  completely (empty commit). With --index there's no need for -a in
  commit either.

(cherry picked from commit 3f698977435bb8730e0865322f8a4856b0bb16af)
A boolean flag is not sufficient to cover three different states...

- HEADERFLAG_SORTED flag bit has been used to track the header
  sort state since beginning of times, but the header sort actually
  has three different states: truly unsorted (such as after additions),
  sorted by index achieved with headerSort(), or sorted by offset which
  is creatively called headerUnsort() in the API.

  There's exactly one place that requires offset sorting, namely
  headerExport(). It does call headerUnsort() explicitly, but
  headerUnsort() would not do anything unless the header was in
  index-sorted state. This is quite often the case, but data addition
  would unset the sorted-flag, and causing headerUnsort() not to
  do anything at all when it most certainly should have. That incorrect
  sorting caused headerExport() calculations to be wildly off.

  This ancient bug was unearthed by the innocent looking
  commit eae671556470136c37951f53ca966cd1bd09aac4: prior to that,
  in half the cases headerSizeof() used to be called first, causing
  index-sorting to take place, after which the headerUnsort() in
  headerExport() did the right thing. In the other two cases
  headerSizeof() was called afterwards, and the headerExport() would
  be garbage in cases where new data had been just added, such as package
  installation. With headerExport() eliminating the need to call
  headerSizeof() all the cases became broken as the header would
  seem much bigger than it is due to the bad sort order and cause
  cases like RhBug:953719 where a largish header suddenly appears
  to be oversized, causing mysterious install failure. Prior to the
  commit (which in itself IS innocent) the issue would've mainly
  manifested in cases where the header needs to be rewritten, which
  only happens when files are replaced and the header is rewritten for that.

(cherry picked from commit da3a3a14e757ccd517e2eb2a3f0293ff48b3ff7f)
Of EACCES, EROFS and EINVAL, only EINVAL is amiguous on env open

- commit 58c5eb28d5f267313294486c6f8a7a6c84984d86 added the errno
  match check, but its only relevant for EINVAL which can be
  returned for non-system errors too, the others are always system
  errors regardless of what errno might hold at the point we get
  to check it.

(cherry picked from commit 902ecd6fd60aaea9e7955b6f54540e14fb58d5f9)
Clarify the dependency version sanity check error message

- Introduced in commit b2cf1471bbe2c35e3c36510a9e3f59919d8ed2c8, the
  original message appeared hard to decipher in real-world testing...

(cherry picked from commit 67ccf8d99630f4edad0ea16dddaca0a3355fba00)
Preparing for rpm 4.11.2-rc2