presence: limit the number of subscriptions handled in timer_dbonly

[lazedo]

Pre-Submission Checklist

• Commit message has the format required by CONTRIBUTING guide
• Commits are split per component (core, individual modules, libs, utils, ...)
• Each component has a single commit (if not, squash them into one commit)
• No commits to README files for modules (changes must be done to docbook files
  in doc/ subfolder, the README file is autogenerated)

Type Of Change

• Small bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds new functionality)
• Breaking change (fix or feature that would change existing functionality)

Checklist:

• PR should be backported to stable branches
• Tested changes locally
• Related to issue #XXXX (replace XXXX with an open issue number)

Description

due to the way update_db_subs_timer_dbonly handles the query to the
database (getting all records), if for some reason a burst of
terminating subscriptions occurs, most likely there will be no package
memory to process all expiring subscriptions.

this commit uses the same pattern as other routines in presence by using
db_fetch_query with fetch_rows parameter module.

because we create the subs in the loop and then call handle_expired_subs
to avoid locking issues the subscription should already be deleted from
the database when it returns from handle_expired_subs, there's no reason
to issue the last delete, and that was removed.

[miconda]

If the removal of the delete at the end was tested properly without side effects, I am fine to merge.

[lazedo]

@miconda yes it was, the callback of the notify deletes the subscription. it actually is required because in the case where we have fetch_rows=500 and the entire result set is 5000 rows then we would loose 4500 rows because they would be deleted.

[lazedo]

this is causing problems in some production servers and i would like to backport to stable branches if that's ok

[miconda]

Ok to backport.