Check if hot_standby_feedback default value needs to be changed

With https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1416 we exposed the config while we do some testing.

If the testing is ok, discuss if it makes sense to change the default value.

/cc @gitlab-build-team @yorickpeterse

I would leave the default as-is. Enabling hot_standby_feedback can increase the number of dead tuples on the primary. For GitLab.com this is not a big deal because we now have rather aggressive vacuuming settings, but it might be problematic for other users. The database load balancer does retry queries in the event of a conflict, so technically this option is not required; it just removes the need for retrying.

To clarify how this option works:

When you have a bunch of replicas they will not vacuum tables themselves, instead this is handled by just updating data per the WAL. When a replica is in hot-standby mode it's possible for a client to run a query that processes data that is being vacuumed. For example, on the primary 100 users are removed while simultaneously these are queried on a secondary. Depending on how long these queries take to run they might be cancelled by the replica so it can apply the WAL changes. This is known as a "hot standby query conflict" (or something along those lines).

When hot_standby_feedback is set to on a replica will tell the primary what queries it's running on a periodic basis. This will then delay vacuuming a bit (not 100% sure about the internals) so queries don't need to be terminated. This means fewer to no conflicts, at the cost of potentially more dead tuples for a period of time. This is mostly problematic when you have many very slow queries operating on data that is being vacuumed all the time.