Fix a framing bug when reading versions from a versions cell.

Our ++ should have been += 2.  This means that we'd accept version
numbers even when they started at an odd position.

This bug should be harmless in practice for so long as every version
number we allow begins with a 0 byte, but if we ever have a version
number starting with 1, 2, 3, or 4, there will be trouble here.

Fix for bug 8059, reported pseudonymously. Bugfix on 0.2.0.10-alpha
-- specifically, commit 6fcda529, where during development I
increased the width of a version to 16 bits without changing the
loop step.

changes/bug8059

@@ -0,0 +1,6 @@
+  o Minor bugfixes (protocol conformance):
+    - Fix a misframing issue when reading the version numbers in a
+      VERSIONS cell. Previously we would recognize [00 01 00 02] as
+      'version 1, version 2, and version 0x100', when it should have
+      only included versions 1 and 2. Fixes bug 8059; bugfix on
+      0.2.0.10-alpha. Reported pseudonymously.

src/or/channeltls.c

@@ -1208,7 +1208,7 @@ channel_tls_process_versions_cell(var_cell_t *cell, channel_tls_t *chan)
 
   tor_assert(chan->conn->handshake_state);
   end = cell->payload + cell->payload_len;
-  for (cp = cell->payload; cp+1 < end; ++cp) {
+  for (cp = cell->payload; cp+1 < end; cp += 2) {
     uint16_t v = ntohs(get_uint16(cp));
     if (is_or_protocol_version_known(v) && v > highest_supported_version)
       highest_supported_version = v;