PS-11256 [DOCS] - Add documentation related to group_replication_flow…

[patrickbirch]

…_control_mode=MAJORITY and related variables/status 8.4

modified:   docs/group-replication-flow-control.md

[Tusamarco]

Well we have few things here that I think we should correct/clarify.
As I have prove here https://www.percona.com/blog/the-failover-brownout-rethinking-high-availability-in-mysql-group-replication/
Flow control do not prevent the nodes to fail behind.
It merely is an indication to the cluster to try to reduce the applyer_queue.
So the expectation is that the cluster will try to reduce the queue down to the given limit, but if not able to, will simply continue to run, it will never stop.
This is has as direct effect that secondary MAY and WILL have a different state of the applied data.
The direct effect are:

• certification buffer will increase on Primary/Secondary
• in case of failover the cluster will elect the new Primary but will keep it in read-only state until the queue is processed
  A correlated settings in the variables is replication appliers (replica_parallel_workers) this variable should be set as replica_parallel_workers = cores * 2.5
  This will help to manage the queue more efficiently but is do not guarantee that FC will prevent nodes to lag behind.