AddressSanitizer:DEADLYSIGNAL in replication.c

Hello, we found one memory issue about DEADLYSIGNAL reported by the AddressSanitizer in version 0.14.0. The following is the bug report:

```
LIBRAFT 1679628518277105579 src/replication.c:1234 restored snapshot with last index 10821
AddressSanitizer:DEADLYSIGNAL
=================================================================
==187672==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000100 (pc 0x7f0e273aaf31 bp 0x7f0dfa6cfe00 sp 0x7f0dfa6cf5b8 T6)
==187672==The signal is caused by a READ memory access.
==187672==Hint: address points to the zero page.
#0 0x7f0e273aaf31 /build/glibc-6iIyft/glibc-2.28/string/../sysdeps/x86_64/multiarch/strlen-avx2.S:65

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /build/glibc-6iIyft/glibc-2.28/string/../sysdeps/x86_64/multiarch/strlen-avx2.S:65
Thread T6 created by T0 here:
#0 0x48cb8c in pthread_create (/opt/fs/dqlite/app+0x48cb8c)
canonical/raft#1 0x7f0e27661860 in dqlite_node_start /opt/fs/dqlite/src/server.c:712:7
canonical/raft#2 0x9d08ec in _cgo_a25baf6e879d_Cfunc_dqlite_node_start /tmp/go-build/cgo-gcc-prolog:281:11

==187672==ABORTING
```

Reproduce the AddressSanitizer failure against version 0.14.0, then inspect src/replication.c:1234 and the startup path at src/server.c:712. Trace the null read reported by strlen and confirm the failure under ASan. Done means the crash cause is addressed and the same scenario completes without an ASan error.

Written by the indexing model from the issue text.