Don't infer we have a FooPort from the presence of a FooPort line

Thanks to the changes we started making with SocksPort and friends
in 0.2.3.3-alpha, any of our code that did "if (options->Sockport)"
became wrong, since "SocksPort 0" would make that test true whereas
using the default SocksPort value would make it false.  (We didn't
actually do "if (options->SockPort)" but we did have tests for
TransPort.  When we moved DirPort, ORPort, and ControlPort over to
the same system in 0.2.3.9-alpha, the problem got worse, since our
code is littered with checks for DirPort and ORPort as booleans.

This code renames the current linelist-based FooPort options to
FooPort_lines, and adds new FooPort_set options which get set at
parse-and-validate time on the or_options_t.  FooPort_set is true
iff we will actually try to open a listener of the given type. (I
renamed the FooPort options rather than leave them alone so that
every previous user of a FooPort would need to get inspected, and so
that any new code that forgetfully uses FooPort will need fail to
compile.)

Fix for bug 6507.

1 files changed, 7 insertions, 0 deletions

diff --git a/changes/bug6507 b/changes/bug6507
new file mode 100644
index 0000000000..5ca02984bd
--- /dev/null
+++ b/changes/bug6507
@@ -0,0 +1,7 @@
+  o Major bugfixes:
+    - Detect 'ORPort 0' as meaning, uniformly, that we're not running
+      as a server. Previously, some of our code would treat the
+      presence of any ORPort line as meaning that we should act like a
+      server, even though our new listener code would correctly not
+      open any ORPorts for ORPort 0. Similar bugs in other Port
+      options are also fixed. Fixes bug 6507; bugfix on 0.2.3.3-alpha.