Brittle behavior when running with bridges and NumEntryGuards=2

During my experiments in #40157 (closed) I noticed that my Tor client would stop working in the middle of the experiment when I was running with bridges and two guards (NumEntryGuards=2): [notice] Application request when we haven't used client functionality lately. Optimistically trying known bridges again.

I found out that if one of the two bridges was down, Tor stops working because guard_selection_get_err_str_if_dir_info_missing() could not find the descriptor of that bridge, and would report it as missing directory info and block circuit attachments in circuit_get_open_circ_or_launch().

This does not seem like the right behavior because one of the two bridges is still up and we should be using that instead of completely giving up.

More investigation is needed to find out if this can happen if a user has configured more than one bridges but has NumEntryGuards=1 (the default). Or if this can ever happen with regular guards and NumEntryGuards=2.

The fix might be to special case bridges here, or to make our guard dirinfo logic a bit more intelligent.

[As a smaller bug here, num_primary_to_check in guard_selection_get_err_str_if_dir_info_missing() is set to 3 in the case of two bridges and NumEntryGuards=2 which is inaccurate because we don't have three primary guards. I don't think this has an effect on the behavior though.]