[FEATURE] Change locking implementation

[imyousuf]

Is your feature request related to a problem? Please describe.
Should we use SELECT FOR UPDATE ... WITH SKIP LOCKED to fetch the rows in GetScheduledMessagesForChannel? The concurrently running schedulers will skip fetching rows that are already fetched by another scheduler. If we do the SELECT FOR UPDATE ... WITH SKIP LOCKED query and creation of messages from scheduled messages in the same transaction, we don't have to acquire locks for each message individually. Reduced lock contention should result in lower load on the db.

https://dev.mysql.com/blog-archive/mysql-8-0-1-using-skip-locked-and-nowait-to-handle-hot-rows/
https://blog.appsignal.com/2025/05/07/an-introduction-to-solid-queue-for-ruby-on-rails.html#on-performance

Describe the solution you'd like
Discussed above

Describe alternatives you've considered
The current implementation is alternate

Additional context