If the ExtORPort doesn't report an external IP address, Tor won't apply rate limiting or account for bandwidth on that connection

In the early days of Tor pluggable transports, on the server side you would run the bridge and the server component of the pluggable transport next to each other, and from Tor's perspective the connection would come in from 127.0.0.1 (i.e. "from the obfs4 server sitting next to the bridge"). And because Tor doesn't apply rate limiting to connections from localhost, it wouldn't rate limit connections coming in via the pluggable transport, and also it wouldn't count bytes to/from that connection in its extrainfo counts or in its BW controller events.

We improved the situation by inventing the "ExtORPort", or "Extended ORPort", which has a quick handshake at the front that specifies e.g. what address the connection is "really" from, and then Tor treats the or_connection_t as though it came directly from that external address. So far so good.

But if the ExtORPort handshake doesn't specify an address, then Tor defaults to 127.0.0.1 (or wherever the server-side of the PT actually is), meaning it resumes having the "no rate limit, no bandwidth accounting" original behavior. That's no good, and we've hit this bug in practice because of a Snowflake bug (legacy/trac#33157 (moved)).

I propose three fixes:

(A) In our documentation for setting up bridges, make it clear that setting an ExtORPort to go with your server-side PT is not just for user count statistics, but it is needed if you want rate limiting and proper bandwidth accounting and reporting.

(B) We could go farther here and tell server-side pluggable transports to demand an ExtORPort from Tor (i.e. refuse to start if you aren't given one). I think this is a good idea, but let me know if you see downsides.

(C) Do something smart with connections over the ExtORPort if they show up without a USERADDR command. I don't know of any concrete reasons why picking a dummy non-internal probably-not-routable address like 255.255.255.255 would break things, but also this is a fine opportunity to do something that doesn't leave future generations shaking their fist at us. For example: add a flag to connection_t called is_external_for_rate_limiting (or a catchier paint color name) where if it's 1 then yes it's external, and if it's 0 then you have to go check the address like before. And then eventually we'd transition more of Tor to use that flag, rather than recomputing whether to apply rate limiting many times over the course of a connection's lifetime.