Bluetooth samples: Broadcast code handling

[jthm-ot]

The broadcast sink sample no longer treats the broadcast_code_received semaphore as a boolean.

Fixes #75469

[Thalley]

Does the broadcast sink without a broadcast source get stuck at

		/* sem_broadcast_code_received is also given if the
		 * broadcast is not encrypted
		 */
		printk("Waiting for broadcast code\n");
		err = k_sem_take(&sem_broadcast_code_received, SEM_TIMEOUT);
		if (err != 0) {
			printk("sem_broadcast_code_received timed out, resetting\n");
			continue;
		}

now?

[jthm-ot]

Do you mean without a broadcast code? If encrypted then sink gets stucked until code provided via broadcast_code_cb. If not encrypted then semaphore is given on syncable_cb

[Thalley]

Right. You are still giving the semaphore.

Since the semaphore is

K_SEM_DEFINE(sem_broadcast_code_received, 0U, 1U);

then it could never be given twice, so what does this PR actually change?

Doesn't

	k_sem_reset(&sem_broadcast_code_received);
	k_sem_give(&sem_broadcast_code_received);

and

	k_sem_give(&sem_broadcast_code_received);

both always set the semaphore count to 1?

[jthm-ot]

When the sem is reset then wait in the main loop hits an error and does a continue => reset

	printk("Waiting for broadcast code\n");
	err = k_sem_take(&sem_broadcast_code_received, SEM_TIMEOUT);
	if (err != 0) {
		printk("sem_broadcast_code_received timed out, resetting\n");
		continue;
	}

[Thalley]

Ah, so if k_sem_reset while k_sem_take is waiting, then it returns an error? Was not aware of that, but yeah I can see that from the documentation now. Nice catch