Restrict GUARDS set to EntryNodes when the set of guards is restrictive

In proposal 271, I suggested that when EntryNodes is a very restrictive set, we should use it, rather than GUARDS, to build our sample.

We already support having a separate guard selection here in the new guard code (see #19888 (moved)), but we don't restrict the GUARDS input set in the way I had suggested yet.

changed milestone to %Tor: 0.3.0.x-final

added TorCoreTeam201612 actualpoints::.1 component::core tor/tor milestone::Tor: 0.3.0.x-final owner::nickm parent::20822 points::2 priority::very high regression resolution::implemented severity::normal status::closed tor-guard type::defect labels

Trac:
Keywords: N/A deleted, tor-guard added

Trac:
Owner: N/A to nickm
Status: new to accepted
Priority: Medium to Very High
Keywords: tor-guard deleted, tor-guard regression added

Trac:
Points: N/A to 2
Keywords: tor-guard regression deleted, tor-guard regression TorCoreTeam201612 added

This was way, way easier than I had expected.

Implementation in ticket20826, on top of prop271_030_v1.

Trac:
Cc: N/A to asn
Status: accepted to needs_review
Actualpoints: N/A to .1

Kind of a kludgy fix but I can see why it works! I wonder how we could do this more cleanly instead of special-casing restricted mode in that function.

If no obvious better way, perhaps we can add a bit of motivation on the new comment?

I've added a bit of a comment to the branch.

new comment lgtm. i think we can proceed with this.

Trac:
Status: needs_review to merge_ready

Rebased and squashed as ticket20826_v2

Merged!

Trac:
Resolution: N/A to implemented
Status: merge_ready to closed

closed

changed time estimate to 16h

added 48m of time spent

moved to tpo/core/tor#20826 (closed)