nvproxy: stop validating client-supplied NVOS64_PARAMETERS.ParamsSize on alloc

[copybara-service]

nvproxy: stop validating client-supplied NVOS64_PARAMETERS.ParamsSize on alloc

The NV_ESC_RM_ALLOC handlers rejected allocations whose
NVOS64_PARAMETERS.ParamsSize did not equal the size of nvproxy's struct
for the allocation class. This is incorrect: the NVIDIA kernel driver
ignores the client-supplied ParamsSize entirely and derives the
parameter size from the class itself. See
src/nvidia/src/kernel/rmapi/alloc_free.c:serverAllocApiCopyIn(), which
initializes the copy size to 0 and sets it via rmapiParamsCopyInit() =>
rmapiGetClassAllocParamSize() (src/nvidia/src/kernel/rmapi/resource_desc.c),
reading RsResInfoByExternalClassId(hClass)->allocParamSize. The user's
ParamsSize is never compared against it, so clients may legitimately pass
ParamsSize == 0 (or any other value) and the allocation still succeeds.

This broke NV_IMEX_SESSION (class 0x000000f1): nvidia-imex passes a
ParamsSize that differs from sizeof(NV00F1_ALLOCATION_PARAMETERS), and
nvproxy returned EINVAL where the host driver would have succeeded.

The check was added for NV_IMEX_SESSION and NV_MEMORY_MULTICAST_FABRIC in
commit 69b0b74 ("nvproxy: translate pOsEvent FD for
NV_MEMORY_MULTICAST_FABRIC allocations"). rmAllocSimpleParams() carried a
pre-existing variant of the same check; it avoided breakage only because
of its "ParamsSize != 0" guard, but would still have wrongly rejected a
non-zero mismatching size from a differing client ABI revision.

Drop the check from rmAllocSimpleParams(), rmAllocIMEXSession(), and
rmAllocMulticastFabric(). nvproxy copies in the fixed-size struct for the
class regardless of ParamsSize, so there is no buffer-safety reason to
validate it. The NV_ESC_RM_CONTROL (NVOS54) ParamsSize checks are left
unchanged, since control commands carry a client-specified parameter size
that the driver does honor.