Fix xnetsocket recvfrom never populating the from_addr due to fromlen being zero

[jonathanou]

What does this Pull Request accomplish?

Fix xnet socket grpc service RecvFrom implementation incorrectly passing 0 as fromlen to the xnet socket recvfrom C API.

Why should this Pull Request be merged?

When calling recvfrom grpc API, I noticed that the from_addr is never filled in.

service NiXnetSocket {
    // ...
    rpc RecvFrom(RecvFromRequest) returns (RecvFromResponse);
}

message RecvFromResponse {
  int32 status = 1;
  bytes data = 2;
  SockAddr from_addr = 3;  // <--- this structure is never populated
  string error_message = 4 [deprecated = true];
  int32 error_num = 5 [deprecated = true];
}

recvfrom is used by UDP sockets to receive a datagram packet, the RecvFrom grpc service code is implemented like this:

::grpc::Status NiXnetSocketService::RecvFrom(::grpc::ServerContext* context, const RecvFromRequest* request, RecvFromResponse* response)
{
    // ...
    auto from_addr = allocate_output_storage<nxsockaddr, SockAddr>();
    nxsocklen_t fromlen {};
    auto status = library_->RecvFrom(socket, (char*)data.data(), size, flags, &from_addr, &fromlen);
}

from_addr is a structure that library_->RecvFrom will fill in with the remote address that sent the datagram packet; the fromlen parameter tells the API the size of the from_addr structure.

The currently generated grpc service code initializes fromlen as 0:

nxsocklen_t fromlen {};

However, the recvfrom C implementation will only populate from_addr if fromlen is NOT 0:

if (from != (struct sockaddr *)0 &&  fromlen != (FNS_SOCKLEN_T *)0  &&  *fromlen)

By passing 0, from_addr structure is never populated, leaving the grpc caller unable to retrieve information about the client address that sent the packet.

What testing has been done?

Manually tested that by setting fromlen to sizeof(from_addr.storage) the grpc call is now getting the client address.