Cannibalizing a circuit should check that first hop is in our guard state

I noticed this on my v3 hidden service info logs which happened on Nov 22nd:

Nov 22 20:04:24.000 [info] internal (high-uptime) circ (length 4, last hop ThomasBernhardsHose): $175921396C7C426309AB03775A9930B6F611F794(open) $77159B89F39708B27CAC528FF32DD786569A11A5(open) $EE2D39A31F09EDD15B887B6EE7AB1396E52C3730(open) $A40E1C039224FA8072C7C84F729236FD738C69DA(open)
Nov 22 20:04:24.000 [info] connection_edge_process_relay_cell(): circuit_send_next_onion_skin() failed.
Nov 22 20:04:24.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Nov 22 20:04:24.000 [warn] circuit_receive_relay_cell (backward) failed. Closing.

So that circuit above has a Guard (175921396C7C426309AB03775A9930B6F611F794) that was removed a minute or so before:

Nov 22 20:03:39.000 [info] sampled_guards_update_from_consensus(): Removing sampled guard lovejoy ($175921396C7C426309AB03775A9930B6F611F794): it was sampled over 120 days ago, and confirmed over 60 days ago.

Turns out that the circuit was cannibalized but tor made it failed because I assume our guard state wasn't available for that circuit which ultimately triggered those warnings. asn informed me that it is important that the circuit with old guard(s) stay alive for a while to help mitigate Guard discovery attacks.

Bottom line, I think our cannibalized function should exclude any circuit that doesn't match our guard state. In the meantime, those warnings will appear in the logs.