Add database abstraction for setting field on multiple objects

What does this MR do?

This abstracts the practice of setting a series of rows with new custom values by ID.

This was used in a couple of places, and by abstracting it, we can remove database specific code from models, and aim to faster less coupled tests.

Downsides:

• passing binding values to a low level API such as exec_query is a private API, so this may break during upgrades. Nevertheless, this is a somewhat common thing to do in order to bypass the limitations of the ARel ORM.
• using binding parameters requires using DB specific binding syntax. This will require changes if we ever choose to support other databases than PG.

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry - Since this a developer facing change, no changelog is necessary
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team