Bluetooth: Add BT_LE_ADV_CONN_ONE_TIME

[alwa-nordic]

The adv auto resume feature is planned for deprecation. This new define is the new default applications should use.

Once this is in, I will post a series of PRs to switch all in-tree users over to this.

[Thalley]

With the auto-resume being removed in the future, wouldn't this also remove the BT_LE_ADV_OPT_ONE_TIME macro as well?

In which case the implementation and definition of BT_LE_ADV_CONN_ONE_TIME will become redundant?

[alwa-nordic]

With the auto-resume being removed in the future, wouldn't this also remove the BT_LE_ADV_OPT_ONE_TIME macro as well?

In which case the implementation and definition of BT_LE_ADV_CONN_ONE_TIME will become redundant?

If you ignore the names, and look at the semantics, then it's BT_LE_ADV_CONN that becomes unsupported. So I'm thinking we could remove that and keep BT_LE_ADV_CONN_ONE_TIME. The tacked-on "_ONE_TIME" would just be a historical oddity.

I'm open to suggestions for a different path, though.

If we decide to silently alter meaning of BT_LE_ADV_CONN instead, then BT_LE_ADV_CONN_ONE_TIME is the temporary name for what will be BT_LE_ADV_CONN once we remove the uses of the current BT_LE_ADV_CONN.

It's of course possible to replace the uses of BT_LE_ADV_CONN with the body of the macro and add BT_LE_ADV_OPT_ONE_TIME, if we prefer. But, I think that would be messier.

[Thalley]

With the auto-resume being removed in the future, wouldn't this also remove the BT_LE_ADV_OPT_ONE_TIME macro as well?
In which case the implementation and definition of BT_LE_ADV_CONN_ONE_TIME will become redundant?

If you ignore the names, and look at the semantics, then it's BT_LE_ADV_CONN that becomes unsupported. So I'm thinking we could remove that and keep BT_LE_ADV_CONN_ONE_TIME. The tacked-on "_ONE_TIME" would just be a historical oddity.

I'm open to suggestions for a different path, though.

If we decide to silently alter meaning of BT_LE_ADV_CONN instead, then BT_LE_ADV_CONN_ONE_TIME is the temporary name for what will be BT_LE_ADV_CONN once we remove the uses of the current BT_LE_ADV_CONN.

It's of course possible to replace the uses of BT_LE_ADV_CONN with the body of the macro and add BT_LE_ADV_OPT_ONE_TIME, if we prefer. But, I think that would be messier.

Removing BT_LE_ADV_OPT_ONE_TIME and defaulting to that behavior is going to be a huge change for nearly all non-extended advertising applications. I'd expect 90%+ of all Zephyr application that use BT will suffer from this. Replacing BT_LE_ADV_CONN with BT_LE_ADV_OPT_ONE_TIME is not really going to help them migrate. Maybe this change is not useful at all

[jori-nordic]

We were actually discussing deprecation in general w/ @alwa-nordic today:
It'd be nice if we always followed a 3-step process:

1. Introduce new API (BT_LE_ADV_CONN_ONE_TIME)
2. Add deprecation warning, users are supposed to switch. In-tree users switch ASAP.
3. Remove old API (BT_LE_ADV_CONN)

In our case, Aleks is doing 1. in this PR, and will do 2. as soon as it's merged. Applications still have the chance to migrate for two releases.

The naming could be better ("single-shot" maybe?). What it's got going for it is that it keeps the same terminology as the BT_LE_ADV_OPT_ONE_TIME. That option has been there for a long time, so users will understand what it means immediately.

All these words to say that I support this PR :)