Don't second-guess REPLACE's behaviour when updating log_online

I have no idea what the rationale behind this logic was, but it's just
all wrong. The session is the primary key, and REPLACE (or SMF's
REPLACE emulation for PostgreSQL) will take care of ensuring uniqueness
for us.

Since this DELETE doesn't check the session and uses dubious logic to
check what to delete (as far as I can tell, this would have nuked *all*
records older than this session's last activity when a guest is
updated), it was actually worse than just letting REPLACE do its thing.
So, goodbye wonky mystery code, hello doing the right thing.

The actual symptom that led me to discovering this problem is that the
PostgreSQL error log gets spammed with duplicate key errors with the
code as it was previously.