Don't pass MM_DONT_ZERO_ALLOCATION to MmAllocatePagesForMdlEx()...

Don't pass MM_DONT_ZERO_ALLOCATION to MmAllocatePagesForMdlEx()...

...in __AllocatePages()

See commit 4f85d004 "Replace uses of MmAllocatePagesForMdlEx in
__AllocatePage" in XENVIF for more background.

In summary, it is to avoid BSOD 139 1e with a stack similar to the following:

nt!KeBugCheckEx
nt!KiBugCheckDispatch+0x69
nt!KiFastFailDispatch+0xd0
nt!KiRaiseSecurityCheckFailure+0x30e
nt!KiAcquireThreadStateLock+0x11fa90
nt!KeSetIdealProcessorThreadEx+0xd0
nt!MiZeroInParallelWorker+0x115016
nt!MiZeroInParallel+0x11c
nt!MiInitializeMdlBatchPages+0x2ae
nt!MiAllocatePagesForMdl+0x192
nt!MmAllocatePartitionNodePagesForMdlEx+0xc9
nt!MmAllocatePagesForMdlEx+0x4d

These bugchecks have been observed in recent updates of Server 2019.

This patch, rather than replacing calls to MmAllocatePagesForMdlEx() with
calls to MmMapLockedPagesSpecifyCache(), just avoids passing
MM_DONT_ZERO_ALLOCATION to work round the bug.

The patch instead passes MM_ALLOCATE_FULLY_REQUIRED, which arguably should
have always been passed for allocations larger than a single page. It also
fixes a formatting issue.

NOTE: Nothing in XENNET currently calls __AllocatePages() so this patch is
      not strictly necessary. However, in case a caller is added in future,
      it is best to keep util.h in sync with the other drivers.

Reported-by: Jan Bakuwel <jan.bakuwel@gmail.com>
Signed-off-by: Paul Durrant <pdurrant@amazon.com>