Fix data race / nil-pointer panic between serve goroutine and Close

[reinkrul]

Problem

Closing a server shortly after Run() can panic in a goroutine that no caller can recover, crashing the test binary:

WARNING: DATA RACE
panic: runtime error: invalid memory address or nil pointer dereference
  github.com/daangn/minimemcached.(*MiniMemcached).serve()  minimemcached.go:125

Root cause

Run() → start() sets m.server = s and spawns go m.serve(). The goroutine loops on m.l.Accept(), reading the embedded listener field on every iteration:

func (m *MiniMemcached) serve() {
	for {
		conn, err := m.l.Accept()   // reads m.l
		...
	}
}

Close() → server.close() concurrently nils that same field:

func (s *server) close() {
	if s.l != nil {
		_ = s.l.Close()
		s.l = nil               // writes m.l
	}
}

Two defects:

• Data race: serve() reads m.l with no lock while Close() writes it under m.mu.
• Nil dereference: if Close() runs before the freshly spawned serve goroutine first reads m.l (common for short-lived servers in unit tests), Accept() is called on a nil listener and panics — in a goroutine the caller cannot recover.

Fix

Capture the listener synchronously in newServer(), which executes during Run() and therefore happens-before any Close() (a caller can only Close() after Run() returns). Pass it into serve() so the goroutine never touches the shared field. Close() still closes the same listener, so the parked Accept() unblocks with an error and serve() returns cleanly.

Test

Adds TestRunClose, which loops Run()/Close(). Under go test -race it reliably reproduces both the data race and the nil-pointer panic on the current code, and passes with the fix.

[MeteorSis]

Thank you for your contribution.