[libvirt] [BUG] mlock support breakage

[Luiz Capitulino]

Libvirt commit c2e60ad0e51 added a new check to the XML validation
logic where XMLs containing <memoryBacking><mlocked/> must also
contain <memtune><hard_limit>. This causes two breakages where
working guests won't start anymore:

1. Systems where mlock limit was set in /etc/security/limits.conf

2. Guests using hugeTLB pages. In this case, guests were relying
   on the fact that libvirt automagically increases mlock
   limit to 1GB

While it's true that <memoryBacking><mlocked/> documentation
says that <memtune><hard_limit> is required, this is actually
an extremely bad request because:

 A. <memtune><hard_limit> own documention strongly recommends
    NOT using it

 B. <memtune><hard_limit> does more than setting memory locking
    limit

 C. <memtune><hard_limit> does not support infinity, so you have
    to guess a limit

 D. If <memtune><hard_limit> is less than 1GB, it will lower
    VFIO's automatic limit of "guest memory + 1GB"

Here's two possible solutions to fix this all:

 1. Drop change c2e60ad0e51 and drop automatic increases. Let
    users configure limits in /etc/security/limits.conf

    pros: this is the most correct way to do it, and how
          it should be done originally IMHO

    cons: will break working VFIO setups, so probably undoable

 2. Drop change c2e60ad0e51 and automtically increase memory
    locking limit to infinity when seeing <memoryBacking><locked/>

   pros: make all cases work, no more <hard_limit> requirement

   cons: allows guests with <locked/> to lock all memory
         assigned to them plus QEMU allocations. While this seems
         undesirable or even a security issue, using <hard_limit>
         will have the same effect

Lastly, <locked/> doesn't belong to <memoryBacking>, it should
be in <memtune>. I recommend deprecating it from <memoryBacking>
and adding it where it belongs.