Fix seldom another sessionbreak memory leak

Another memoryleak appears to be happening but more seldom, see buildbot run:
https://build.rsyslog.com/#/builders/79/builds/323

==5081==
==5081== HEAP SUMMARY:
==5081== in use at exit: 32 bytes in 1 blocks
==5081== total heap usage: 92,822 allocs, 92,821 frees, 3,744,757 bytes allocated
==5081==
==5081== 32 bytes in 1 blocks are definitely lost in loss record 1 of 1
==5081== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711)
==5081== by 0x4E3A41D: addToEpollSet (relp.c:101)
==5081== by 0x4E3AA14: addSessToEpoll (relp.c:147)
==5081== by 0x4E3AA14: relpEngineAddToSess (relp.c:211)
==5081== by 0x4E3AA14: handleConnectionRequest (relp.c:670)
==5081== by 0x4E3AA14: engineEventLoopRun (relp.c:844)
==5081== by 0x4E3B08E: relpEngineRun (relp.c:1024)
==5081== by 0x401C97: main (receive.c:475)
==5081==
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: definite
fun:calloc
fun:addToEpollSet
fun:addSessToEpoll
fun:relpEngineAddToSess
fun:handleConnectionRequest
fun:engineEventLoopRun
fun:relpEngineRun
fun:main
}

Start with the linked buildbot run and trace the allocation path through addToEpollSet, addSessToEpoll, and relpEngineAddToSess in relp.c, with receive.c as the caller entry point. Determine where the 32-byte allocation loses ownership during session handling. Done means the scenario no longer reports a definite leak under Valgrind.