[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...

[sbulen]

I put this into draft mode for now, due to lessons here #9158

[sbulen]

What's going on here, specific to this PR, is that the call to regenerate_session_id() upon login/logout causes PHP to internally rewrite the sessions. Those internally-generated calls to session write have no actions associated with them. So this logic, in its current state, doesn't write the new session. Ooops.

This only impacts logging on via the non-modal login form, the one you get with guest browsing disabled. The login button works fine.

Still thinking through solutions. Getting rid of that login form would fix it. Just replace it with a button. Pretty sure that would fix this and also #9158.