fix advertising parameter usage for legacy advertising

[markusjellitsch]

when using start_adverting() the usage of advertising_interval_min and advertising_interval_max for legacy advertising is not consistent with extended advertising (The advertising_interval given as input param should be calculated in 0.625 units)

[zxzxwu]

This API has been widely used, so we shouldn't roughly alter its spec. At least we should check its type to determine whether it should be considered 1 or 0.625 ms.

[markusjellitsch]

Yes understand. At the moment it's a bit confusing and inconsistent, when you call start_advertising()and legacy adv is used it is 0.625 ms, for extended adv it is 1.

[barbibulle]

I think the change here makes sense. It was never the intention of the API to accept values in units of 0.625 (as a general rule, the Device API tries to hide internal spec details). All those intervals are supposed to be in milliseconds. In fact, for extended advertising, that's what the implementation does.
So this should be considered a bug fix, not an API change.

[barbibulle]

@markusjellitsch could you run the formatter (check with invoke project.pre-commit for details) so that the linter/formatter checks can pass before we merge the change?

[markusjellitsch]

@barbibulle I reverted advertising_interval to float.

[markusjellitsch]

I checked with invoke project.pre-commit and this seems fine (see log below). However Github Actions v3 seems deprecated from now on. Is there anything I can do from my side.

`device_test.py::test_cis
device_test.py::test_cis_setup_failure
/home/markus/projects/bumble/bumble/utils.py:467: FutureWarning: Only for testing
warnings.warn(msg, FutureWarning)

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
================== 347 passed, 1 skipped, 7 warnings in 8.17s ==================
All good!`

[barbibulle]

I'll need to update the GitHub actions, looks like some actions have become obsolete. I'll get to it now.

[barbibulle]

Ah, looks like you've already done that :-)

[barbibulle]

Why not keep float here? While not strictly necessary, I think it's Ok to let the caller pass in non-integer millisecond values, since the spec supports it.

[markusjellitsch]

I reverted it because of pylint expecting int. It would require more code changes (adapt all internal advertising interval member variables to non-int). In the long run I'd definetely allow the caller to set the complete range of allowed values.

I am not sure if this change should be in the scope of this PR :-)

[barbibulle]

Let's leave like as int for now. I thought that float was supposed to imply that you could pass an int too (quoting https://typing.readthedocs.io/en/latest/spec/special-types.html#special-cases-for-float-and-complex ):

Special cases for float and complex
Python’s numeric types complex, float and int are not subtypes of each other, but to support common use cases, the type system contains a straightforward shortcut: when an argument is annotated as having type float, an argument of type int is acceptable; similar, for an argument annotated as having type complex, arguments of type float or int are acceptable.

But maybe pylint isn't following that rule. We can leave that for a separate PR.