thread control panics from unwrap on None

[markpash]

This occurred on a build of the current master. Not sure what else I can provide. Not sure if I'll see the same crash again. Let me know if there's anything more I can do.

01/04/20 14:05:00 [synapse::tracker::dht:156] E: Failed to send message on UDP socket: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }
01/04/20 14:05:14 [synapse::tracker::dht:156] E: Failed to send message on UDP socket: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }
thread 'control' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:378:21
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:77
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:61
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1028
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1412
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:65
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:50
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:188
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:205
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:464
  11: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:373
  12: rust_begin_unwind
             at src/libstd/panicking.rs:302
  13: core::panicking::panic_fmt
             at src/libcore/panicking.rs:139
  14: core::panicking::panic
             at src/libcore/panicking.rs:70
  15: core::option::Option<T>::unwrap
             at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libcore/macros.rs:41
  16: synapse::torrent::choker::Choker::unchoke_random
             at src/torrent/choker.rs:40
  17: synapse::torrent::choker::Choker::remove_peer
             at src/torrent/choker.rs:57
  18: synapse::torrent::Torrent<T>::cleanup_peer
             at src/torrent/mod.rs:1867
  19: synapse::torrent::Torrent<T>::peer_ev
             at src/torrent/mod.rs:939
  20: synapse::control::Control<T>::handle_peer_ev
             at src/control/mod.rs:360
  21: synapse::control::Control<T>::handle_event
             at src/control/mod.rs:285
  22: synapse::control::Control<T>::run
             at src/control/mod.rs:149
  23: synapse::init::init_threads::{{closure}}
             at src/init.rs:82
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
01/04/20 14:07:06 [synapse::init:41] E: Unclean shutdown detected, terminating```

[Luminarys]

There's definitely still instances where peer addition/removal state is handled incorrectly throughout the code. I'll take a look at this specific bit of code, but overall there needs to be some improvements to how peers are treated throughout the system.

[Luminarys]

I've fixed this specific issue.