bluez5: Remove incorrect variant levels.

[fkleon]

The levels were set too high, causing introspection to return type 'v' for all properties, which is incorrect and not matching the BlueZ API.

Additionally, some DBus clients (such as dbus-next) perform type validation at runtime and refuse to process such mismatching properties.

This removes the variant levels and adds a unit test to ensure the introspection details returned by the mocks match the expected API.

[fkleon]

I verified the expected types by comparing the output of gdbus introspect --system --dest "org.bluez" --object-path "/org/bluez/hci0" --recurse between a real device and a mock device.

Some properties should be defined as readonly to match the API specs, which I don't think this library supports. Since this did not trip up any DBus client library I've tested I didn't look into that further.

[martinpitt]

Ugh -- seems I have misunderstood D-Bus properties forever. The D-Bus spec says that all properties have to be wrapped into a variant -- the .Get() and .Set() APIs take/give variants only. Also, dbus docs say that variant_level=1 is wrapped into exactly one variant level, which matches what D-Bus expects.

But apparently somewhere along the line the variant gets added/stripped. So this indeed doesn't just affect bluez5, but all other templates as well.

I'll land this, and then send a follow-up PR for fixing all the others. Thanks for pointing out!

[martinpitt]

This should be self.assertEqual() for better failures.

[fkleon]

Yep, good point. I'm used to running tests with pytest which produces nice failure messages as it rewrites the assert statements internally. Will change it to self.assertEqual() for consistency.

[martinpitt]

Oh, you were quick -- I already fixed that locally and did some other minor cleanups. I'll also push the "fix the rest" commit right here, this really belongs together. I'll take it from here, thanks!

[fkleon]

Ugh -- seems I have misunderstood D-Bus properties forever. The D-Bus spec says that all properties have to be wrapped into a variant -- the .Get() and .Set() APIs take/give variants only. Also, dbus docs say that variant_level=1 is wrapped into exactly one variant level, which matches what D-Bus expects.

But apparently somewhere along the line the variant gets added/stripped. So this indeed doesn't just affect bluez5, but all other templates as well.

I'll land this, and then send a follow-up PR for fixing all the others. Thanks for pointing out!

To be fair, I've looked at those docs multiple times and could never quite make sense of the variant_level and when it's required. It could certainly use some better examples! Other DBus client libraries don't seem to bother explicitly defining the variant level and instead rely on auto-wrapping when required.

I only noticed something was wrong when I used dbusmock with dbus_fast (fork of dbus_next) and couldn't get it to read any properties without type mismatches on the mock objects. Many clients don't seem to bother with typechecking the actual responses against the definition from the introspection, in which case this is silently working.

[martinpitt]

@fkleon Right, seems I fell into the same trap. It seems the usual client libs magically unwrap the extra variant transparently then, as this never came up before. But I confirmed with busctl introspect.

The rawhide NM hang is unrelated, I'll look at that separately. Thanks!