FIX: Avoid syncing user bookmarks for users that are getting destroyed

[nattsw]

When a user is destroyed via UserDestroyer, it first gets its Bookmarks deleted, then its Posts.

In the PostDestroyer, the SyncTopicUserBookmarked job gets called to make sure orphan bookmarks are deleted if the post is a topic. However, this job is not needed when a user is getting destroyed.

This PR adds an opt that indicates to PostDestroyer that this job doesn't need to be scheduled. This PR also optimises the sync job to skip topics where there are no bookmarks.

No bookmarks

# current job
pry(main)> 200.times.sum { Benchmark.realtime { Jobs::SyncTopicUserBookmarked.new.execute(topic_id: 50) }} / 200.0
=> 0.0016186350025236607

# modified job
pry(main)> 200.times.sum { Benchmark.realtime { Jobs::SyncTopicUserBookmarked.new.execute(topic_id: 50) }} / 200.0
=> 0.00028412999818101526

Five bookmarks

# current job
pry(main)> 200.times.sum { Benchmark.realtime { Jobs::SyncTopicUserBookmarked.new.execute(topic_id: 50) }} / 200.0
=> 0.0014668599981814622

# modified job
pry(main)> 200.times.sum { Benchmark.realtime { Jobs::SyncTopicUserBookmarked.new.execute(topic_id: 50) }} / 200.0
=> 0.0008136450103484094

[martin-brennan]

As discussed internally we need to collect all the destroyed topic IDs and run the SyncTopicUserBookmarked job at the end of UserDestroyer (we need to modify the job for this)

[martin-brennan]

As noted internally, the perf of this worries me a bit; the tmp_sync_topic_user_bookmarks way was done because there are potentially a lot of records changing here.

[martin-brennan]

Since this is a query for a value now, this should be DB.query_single . IIRC the return value of exec is based on success of the query, not the actually return value.

[martin-brennan]

Suggested change

	return unless bookmarks_exist
	return if !bookmarks_exist

This is a Sam special :P

[jjaffeux]

@martin-brennan @nattsw do we still want to get this merged?