[3.0] Bots - reduce session writes

[sbulen]

3.0 version of #9126 - More discussion may be found there.

This PR aims to minimize I/O during a bot attack by eliminating unnecessary duplicative session writes. Session writes spike during botnet attacks, and the database management, e.g., the undo/redo logs, can get backed up with the extremely high volume of updates.

As it is today, at least one session update occurs any time index.php is invoked. Multiple session writes can occur, e.g., during redirects, attachment loads, notification checks, verifications, keepalives, and any time a bot passes a bogus session via URL or cookie.

The approach used here is to simply not write sessions during normal browsing activity, e.g., boards, topics, & messages. Sessions will be written whenever an action is taken; this avoids any loss of functionality dependent on the session.

Note that some of these bot attacks are what I call 'long tail' attacks, in which many IPs are used once and only once. This was a trademark of the 2025 Q3 Brazil/Vietnam attack; on some days, I would have 150,000+ IPs with only one topic or message request each... The problem being that each would get its own unique session & log_online record, causing a flood of writes & log activity. And then, of course, they would all need to be deleted during garbage collection.

With this change, they wouldn't be written at all.

One of the reasons so many sessions are written is that they are timestamped by SMF during the actual write, forcing each session write to be unique. My understanding is that this thwarts PHP's normal session update checks, as they would normally only be written when real updates occur. That may be an avenue for further testing & savings. At the moment, I'm not sure what the impacts would be of removing that particular timestamp.

For more discussion see:
https://www.simplemachines.org/community/index.php?topic=592442.0
https://www.simplemachines.org/community/index.php?topic=592345.0

[sbulen]

Third time's a charm...