[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 to get the new id out there. 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.

[sbulen]

My current thinking on this PR & it's 2.1 equivalent is to wait until after #9167 is merged to resume testing.

There are definite issues with no-guest-browsing forums with this PR, which will be addressed in #9167, so there is a dependency.

[jdarwood007]

I've merged #9167
Is there a way to test the issues you're still seeing?

[jdarwood007]

Is this ready to go? Its 2.1 counterpart shows ready

[sbulen]

The 3.0 version needs work. I'll work on this.

I generally wait until we're closer to merging update the 3.0 versions, to minimize testing cycles...

Give me a day or two.

[sbulen]

Up-to-date, & tested. Looks good.

There was an unrelated error that I'll log separately.