sanlock: fix release writing zero dblock values
    
    Incorrect use of release_token was leading to a case
    where zero values would be written into the dblock.
    
    As mentioned in other code comments, it is unsafe for
    a host to write zeros values into its dblock, because
    those zero values can be used by, and alter the results
    of, a paxos ballot that is still running on other hosts.
    This can lead to multiple hosts running a paxos ballot
    for the same leader version an reaching different
    results, i.e. multiple owners of the lease at the same
    time.
    
    This was observed when a host running a paxos ballot
    commits another host as the owner, so fails to acquire
    the lease for itself, and returns SANLK_ACQUIRE_OTHER.
    After this, the code calls release_token, which was
    mistakenly called in way that would write zeros to
    the dblock (and mblock).  A new variant of release_token
    is now used to avoid writing the dblock in this case.
    
    Original report and diagnosis from 山吴.