Failing to set private key before peers makes socket unresponsive

[Steve Kerrison]

If boringtun is given peer settings without the private key being set, it will panic and the socket will end session without providing a response. Subsequent requests to the socket yield no response.

To reproduce:

1. Run a boringtun:

RUST_BACKTRACE=1 boringtun myvpn -v debug -l /dev/stdout -f
Feb 08 02:43:49.373 INFO BoringTun started successfully

2. Check socket works:

socat - UNIX-CONNECT:/var/run/wireguard/myvpn.sock 
get=1
listen_port=51601
errno=0

3. Issue a set without the private key:

socat - UNIX-CONNECT:/var/run/wireguard/myvpn.sock 
set=1
listen_port=12345
public_key=6040ad1d02595ad318d7b54673de74361d7cce0a1a617da5b851031243abe67a
endpoint=1.2.3.4:5678

4. Observe no response from set, and observe error:

thread '<unnamed>' panicked at 'Private key must be set first', src/device/mod.rs:337:14
stack backtrace:
   0: rust_begin_unwind
             at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:495:5
   1: core::panicking::panic_fmt
             at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/panicking.rs:92:14
   2: core::option::expect_failed
             at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/option.rs:1260:5
   3: boringtun::device::Device<T,S>::update_peer
   4: boringtun::device::api::api_set_peer
   5: boringtun::device::dev_lock::LockReadGuard<T>::try_writeable
   6: boringtun::device::api::<impl boringtun::device::Device<T,S>>::register_api_handler::{{closure}}
   7: boringtun::device::DeviceHandle<T,S>::event_loop
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

5. Subsequent socket interaction yields nothing:

socat - UNIX-CONNECT:/var/run/wireguard/myvpn.sock 
get=1

It seems that private_key could have been set in a previous set, so it's not necessary for it to be there. But, if it isn't previously set, an appropriate errno response should come back and avoid the panic.