Implement support for per-circuit guard restrictions.

This is an important thing I hadn't considered when writing prop271:
sometimes you have to restrict what guard you use for a particular
circuit.  Most frequently, that would be because you plan to use a
certain node as your exit, and so you can't choose that for your
guard.

This change means that the upgrade-waiting-circuits algorithm needs
a slight tweak too: circuit A cannot block circuit B from upgrading
if circuit B needs to follow a restriction that circuit A does not
follow.

1 files changed, 1 insertions, 0 deletions

diff --git a/src/or/circuitbuild.h b/src/or/circuitbuild.h
index 2c83a16550..b85dbecf7e 100644
--- a/src/or/circuitbuild.h
+++ b/src/or/circuitbuild.h
@@ -61,6 +61,7 @@ int extend_info_supports_ntor(const extend_info_t* ei);
 int circuit_can_use_tap(const origin_circuit_t *circ);
 int circuit_has_usable_onion_key(const origin_circuit_t *circ);
 int extend_info_has_preferred_onion_key(const extend_info_t* ei);
+const uint8_t *build_state_get_exit_rsa_id(cpath_build_state_t *state);
 const node_t *build_state_get_exit_node(cpath_build_state_t *state);
 const char *build_state_get_exit_nickname(cpath_build_state_t *state);