This SELECT option was added when the UPDATE query was split into a
SELECT + UPDATE query pair, in order to try to avoid deadlocks in mariadb.
  commit 7daaf0a5
  Author: Vincent Pelletier <vincent@nexedi.com>
  Date:   Fri Jun 7 16:53:11 2013 +0200

      Work around poor UPDATE use of index.
That was not completely successful, and another attempt was since made,
which further ipmproved the situation:
  commit e21aa47f601a98f767e2d3e8490b20b7f409933c
  Author: Vincent Pelletier <vincent@nexedi.com>
  Date:   Fri Sep 17 11:34:46 2021 +0900

      CMFActivity.Activity.SQLBase: Reduce the number of deadlocks

This change made the "FOR UPDATE" option obsolete: there should be
virtually no parallelism between the SELECT and UPDATE queries.
By which I mean only 3rd-party accesses (like an admin on a mysql console)
would bypass the SQL lock, causing index-update-level locking issues.

Checking now, I see that removing "FOR UPDATE" on the "node>0" query makes
that query (with LIMIT 30) run about 5 times faster:
With FOR UPDATE:    0.509s
Without FOR UPDATE: 0.090s
This difference is enough to cause significant activity starvation on a
63-processing-nodes cluster where such activities run in about 1s, just
because of the amount of contention on the SQL lock, itself because of the
duration of every execution of this query.

So remove this now-redundant option.

It is expected that this will improve activity processing performance in
general, beyond just the starvation issue which led to this discovery.