The "procedure number" has been used for 2 purposes in the kernel
client RPC implementation:

  1) As a number to pass to the server in the RPC header.

  2) As an index into the "procedure array" of type 'struct
     rpc_procinfo', from which the RPC layer can find the XDR
     encode/decode functions, buffer size, and all the other static
     data that it needs to construct the on-wire RPC message.

This works fine for NFSv2, v3 and for the NLM locking code for which
there is a one-to-one mapping between NFS file operations, and RPC
procedures.
For NFSv4 on the other hand, the mapping is many-to-one, since there
is only one RPC procedure number: NFSPROC4_COMPOUND.

For efficiency purposes, we want to have a one-to-one mapping between
NFS file operations and the corresponding XDR encode/decode routines,
but currently this is not possible because of (2). The result is the
mess that is 'struct nfs4_op' and encode/decode_compound.

In the process eliminating (2), we might as well change to passing a
pointer to the appropriate procedure array entry instead of an
index. This change can be made transparent

The appended patch therefore does the following:

   - Substitute a pointer to the rpc_procinfo instead of the RPC
     procedure number in the struct rpc_message.
   - Make the RPC procedure number an entry in the struct
     rpc_procinfo.
   - Clean out the largely unused (except in some obscure lockd
     debugging code) p_name field. The latter was just a stringified
     version of the RPC procedure name, so for those lockd cases, we
     can use the RPC procedure number instead.