Fix cookie contest pseudocode

The cookie contest pseudocode can sometimes produce RESPONDER -
RESPONDER type of peers, because bit 31 is used both as a weight in a
64-bit 2's complement integer, and a sign bit. See the discussion here
for a detailed brief:

Haivision/srt#3208

This should be fixed asap in the RFC such that implementors do not end
up with this bug in their protocol stack.

We propose to avoid the use of bitmasks to
 1) make the intention clearer
 2) let the compiler handle the low-level details

We also propose to add a statement, reminding implementors of the
importance of considering endianness of the host and the network before
comparing the cookies.

squash

Author: kristofferrobinstokke

draft-sharabayko-srt.md

@@ -1663,8 +1663,7 @@ than its peer's, it wins the cookie contest and becomes Initiator
 (the other party becomes the Responder).
 
 The intent is to let the side with the greater cookie value become the Initiator
-(the other party becomes the Responder). However, with a special handling
-of the higher bit of the difference.
+(the other party becomes the Responder).
 
     <CODE BEGINS>
     enum ContestResult
@@ -1680,16 +1679,22 @@ of the higher bit of the difference.
       // host - Local (host) cookie value.
       int64_t contest = int64_t(host) - int64_t(peer);
 
-      if ((contest & 0xFFFFFFFF) == 0)
+      if (contest == 0)
         return DRAW;
 
-      if (contest & 0x80000000)
+      if (contest < 0)
         return RESPONDER;
 
       return INITIATOR;
     }
     <CODE ENDS>
 
+Note that implementations must:
+ - Treat cookies as signed integers in 2s complement format.
+ - The cookies must be sign-expanded to 64 bit signed integers prior to the contest.
+ - Implementations must consider network and host endianness and perform conversions as
+   appropriate.
+
 #### The Waving State {#waving-state}
 
 Both parties start in a Waving state.