Consider session if the client supports tickets but offered a session ID.

This is a minor regression from
https://boringssl-review.googlesource.com/5235.

If the client, for whatever reason, had an ID-based session but also
supports tickets, it will send non-empty ID + empty ticket extension.
If the ticket extension is non-empty, then the ID is not an ID but a
dummy signaling value, so 5235 avoided looking it up. But if it is
present and empty, the ID is still an ID and should be looked up.

This shouldn't have any practical consequences, except if a server
switched from not supporting tickets and then started supporting it,
while keeping the session cache fixed.

Add a test for this case, and tighten up existing ID vs ticket tests so
they fail if we resume with the wrong type.

Change-Id: Id4d08cd809af00af30a2b67fe3a971078e404c75
Reviewed-on: https://boringssl-review.googlesource.com/6554
Reviewed-by: Adam Langley <alangley@gmail.com>
diff --git a/ssl/test/runner/common.go b/ssl/test/runner/common.go
index db3c675..f2ef360 100644
--- a/ssl/test/runner/common.go
+++ b/ssl/test/runner/common.go
@@ -814,6 +814,10 @@
 	// BadHelloRequest, if not nil, is what to send instead of a
 	// HelloRequest.
 	BadHelloRequest []byte
+
+	// RequireSessionTickets, if true, causes the client to require new
+	// sessions use session tickets instead of session IDs.
+	RequireSessionTickets bool
 }
 
 func (c *Config) serverInit() {