acl: fix the integer overflow bug in API message length validation logic
Sending the bogus acl_add_replace message with count=~0 will result in
an overflow of "expected_len" field which is a u32, thus the message
will pass the validation when it should not.
Solution - make the expected_len a u64 to avoid overflow.
The bug was found while experimenting with libfuzzer as part of
https://gerrit.fd.io/r/c/vpp/+/31763
Type: fix
Change-Id: I4a866d48f2418148236f1b1d77c487b869c7c43d
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>