How will this affect Tor's ability to fetch directory information from the DirPort of a relay like dannenberg which has a ‘real web server’ in front of Tor?

Should be unrelated. Basically right now we preemptively malloc a string version of router->addr, and then carry it around ever after for when we need it. We could instead generate it on demand and then not keep it in between uses. Should have no impact on external-visible behavior.

Hmm; the change in the unit test seems to hint at a problem with this: sometimes router->address is set from the public address rather than the address we're listening on, and thus does not always match router->addr. Are we okay with changing every instance of anything using router->address to use the actual listener address?

Hmm; the change in the unit test seems to hint at a problem with this: sometimes router->address is set from the public address rather than the address we're listening on, and thus does not always match router->addr.

I believe this only happens in this one case in the unit tests. Basically, our test assumed that it could set address and addr to different things. Nothing else in the code thinks this.

Are we okay with changing every instance of anything using router->address to use the actual listener address?

Don't be fooled about 'actual listener address' or any of that. router->addr is always set from the IP address in the router descriptor, and router->address was always just the string representation of router->addr (except as you note in the unit tests, where it just fabricates some values and assigns them).