bail out of client_read if we've already decide what to do

libevent2 can still somehowe call client_read even in code paths
that never enable reading from the evbuffer.  Can't reproduce on
the libevent in base on OpenBSD.  It's a bit ugly, but it's a small
workaround for something that otherwise *always* make gmid crash
when linked against libevent2.  (client_read works under the
assumption that c->host != NULL, matched_proxy crashes otherwise.)

regress/regress

@@ -53,5 +53,6 @@ run_test test_macro_expansion
 run_test test_174_bugfix
 run_test test_proxy_relay_to
 run_test test_proxy_with_certs
+run_test test_unknown_host
 
 tests_done

regress/tests.sh

@@ -362,3 +362,11 @@ test_proxy_with_certs() {
 	fetch /
 	check_reply "60 client certificate required" || return 1
 }
+
+test_unknown_host() {
+	setup_simple_test '' ''
+
+	ggflags="-N -H foobar"
+	fetch /
+	check_reply '59 Wrong/malformed host or missing SNI'
+}

server.c

@@ -1004,6 +1004,14 @@ client_read(struct bufferevent *bev, void *d)
 
 	bufferevent_disable(bev, EVBUFFER_READ);
 
+	/*
+	 * libevent2 can still somehow call this function, even
+	 * though I never enable EV_READ in the bufferevent.  If
+	 * that's the case, bail out.
+	 */
+	if (c->type != REQUEST_UNDECIDED)
+		return;
+
 	/* max url len + \r\n */
 	if (EVBUFFER_LENGTH(src) > 1024 + 2) {
 		log_err(c, "too much data received");