tests: Bluetooth: "fix" resume2 bsim test

[jori-nordic]

This test assumes that the link-layer will have the same amount of peripheral slots as central slots.

Force the usage of the Zephyr Link Layer for this one test.

E.g. nCentrals == nPeripherals == BT_MAX_CONN

This might not be true for other controllers:
In nordic's case, the Softdevice Controller takes BT_MAX_CONN as the total number of slots, peripherals + centrals.
In that case, nCentrals = BT_MAX_CONN - 1, nPeripherals = 1.

That test is not designed for this case.

[alwa-nordic]

This is not supposed to be link-layer specific. Either we remove the feature this test specifies, or it has to work everywhere.

[jori-nordic]

it has to work everywhere

Please make it work then

[alwa-nordic]

My preferred fix would be to revert #51256. The resume2 test exists to verify that change, so we remove it as well. @jori-nordic, @jhedberg, would you be OK with this?

Otherwise, we need to exactly specify the behavior that PR is claiming to fix. I've tried - I consulted both the author of the PR, @jori-nordic and others. I don't think this option is actually feasible. Tweaking defaults like this resume limit inevitably just breaks something somewhere.

As an aside, I am also in favor of deprecating the auto-resume feature entirely.

[Thalley]

As an aside, I am also in favor of deprecating the auto-resume feature entirely.

I think this is the best option as well. The stack-initiated scanning feature often cause issues, and significantly increases the complexity of the host.

Furthermore it clearly has had the effect that (nearly) all samples do bt_le_scan_stop before calling bt_conn_le_create, so in the scan recv callback we often see 3 (blocking) HCI calls:

1. Scan stop (from app)
2. Create conn (from app)
3. Scan start (from host)

[alwa-nordic]

The resume2 test exists to verify that change, so we remove it as well.

PS. We can of course repurpose the test to specify the old behavior.