bluetooth: mesh: adv_ext: Fix scheduling with multiple relay adv sets

When multiple relay adv sets are used, the bt_mesh_adv_send function
calls bt_mesh_adv_relay_ready which should distribute relayed
advertisements across all relay adv sets.

Until the submitted relay adv set work is started, the ADV_FLAG_ACTIVE
is not set. Therefore, next call to bt_mesh_adv_send will try to
re-submit the same relay adv set work, instead of picking up another
relay set which is actually free and ready to send an advertisement.

This commit adds a check that checks if the adv set work is already
pending to be executed. And if so, schedule_send returns false to make
bt_mesh_adv_relay_ready pick next relay adv set.

This shouldn't brake advertising because once adv set is done
transmitting advertisment, it will pick up a next one.

The ADV_FLAG_PROXY check is added to do re-submit for adv set which was
used for proxy advertisement since we need to prioritize mesh messages
over proxy advertisements when those are running on the same adv set.

Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>

Author: PavelVPV

subsys/bluetooth/mesh/adv_ext.c

@@ -391,6 +391,16 @@ static bool schedule_send(struct bt_mesh_ext_adv *ext_adv)
 		if (!atomic_test_bit(ext_adv->flags, ADV_FLAG_PROXY)) {
 			return false;
 		}
+	} else if (k_work_is_pending(&ext_adv->work) &&
+		   !atomic_test_bit(ext_adv->flags, ADV_FLAG_PROXY)) {
+		/* This can happen if we try to schedule a send while a previous send is still
+		 * pending in the work queue. There is nothing wrong with resubmitting the same
+		 * work to the work queue, but in this case won't have a change to try a work from
+		 * another advertising set which can be ready for sending.
+		 *
+		 * If, however, ADV_FLAG_PROXY is set, we want to stop the proxy advertising.
+		 */
+		return false;
 	}
 
 	bt_mesh_wq_submit(&ext_adv->work);