When bridges lines leave out the fingerprint, how should controllers look them up by id?

In #32125 (moved) we have a case where the user configures a bridge line but leaves the optional fingerprint out. In this case Tor learns the fingerprint when it connects:

Oct 19 01:42:54.644 [notice] Learned fingerprint 1948xxxxxxxxF6A25E456B7DB9C2D37EFB7250C1 for bridge x.y.153.221:9001.

But most controller events and responses list relays by their identity fingerprint, e.g. here is a line from 'getinfo circuit-status':

12 BUILT $1948xxxxxxxxF6A25E456B7DB9C2D37EFB7250C1~badabim,$E14D10669DD6E472235F8F0161544B4E7B7CB3C7~BOOTCHAROO2,$C3B451E071694ABA3AC2E75D49418E866072E051~HiddenNix,$1D04FF920CE804CE357FE62C665901C578BC26D6~tower BUILD_FLAGS=IS_INTERNAL,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2019-10-19T05:42:56.257467

So when the controller wants to (for example) tell the user about their path, what is the right way for the controller to match up the relay id to the configured bridge?

Tor Browser does it with 'getconf bridges' and looking through the id fingerprints of each configured bridge line until it finds a match. But if the bridge lines in torrc leave out the fingerprint, then you won't find the bridge that way.

We should provide a recommended way for controllers to accomplish this goal (and that might involve building this new way into Tor).

[I cc atagar and pospeselr because they write controllers and might have an opinion; and phw and cohosh because bridges.]

added component::core tor/tor priority::medium severity::normal status::new type::defect labels

One option that comes to mind is that when we learn the fingerprint as we connect to the bridge, inside learned_router_identity(), we could emit a controller event. Then controllers that are listening could annotate their internal state of our bridges on their own, when they see the event. I believe we don't have any event like that currently though. And this idea wouldn't by itself be enough, because controllers only hear controller events when they're already connected, so we would want some way for the controller to ask for the current state.

I found "getinfo ns/purpose/bridge", which asks Tor to fabricate a status entry like one would find in the consensus, for each of its current bridges:

getinfo ns/purpose/bridge
250+ns/purpose/bridge=
r badabim GUj+xxxxxxxxRWt9ucLTfvtyUME lsA8xxxxxxxxB1DIMFPusxQIZsk 2019-10-19 04:30:28 x.y.153.221 9001 0
s Running V2Dir
w Bandwidth=1215
p reject 1-65535
.
250 OK

This is essentially how the bridge authority makes a faux networkstatus document for all the bridges it knows (for export to bridgedb). So we could tell controllers, if they have a relay id and they can't find it in getconf bridge and they can't find it in getinfo ns/id/, to ask for getinfo ns/purpose/bridge and crawl through those results.

Is that our best available option? Is there some better way we should expose this info?

Trac:
Cc: atagar, pospeselr, phw, cohosh to atagar, pospeselr, phw, cohosh, mcs

moved to tpo/core/tor#32157