dbusutil: Type hinting improvements

[sonic2kk]

This PR improves the type hinting in dbusutil.

• Fixes the default argument for bus. basedPyright was warning "Function calls and mutable objects not allowed within parameter default value expression", and when looking it up, it seems this is for good reason. This has been replaced with defaulting the parameter to None and if it is None, assign it to QDBusConnection.sessionBus inside of the function body.
  • This extra definition isn't typed because then it flags up a shadowed definition warning, even if the original hinting was possibly None and you just want to state in the re-definition that it will never be None (I guess the expectation is that the code speaks for itself, and basedPyright is able to infer that the type will never be None)
  • In create_and_send_dbus_message I accidentally set it as QDBusConnection.sessionBus without the parentheses, so if we ever actually called this without bus it would probably have crashed!
• Typed the variables used in the functions that weren't explicitly clear or that came from values accessed from constants.py's DBUS_INTERFACES_AND_SIGNALS constant.
  • The arguments dict is typed as dict[str, Any] in create_and_send_dbus_message because DBus should always get a string key (e.g. progress) but the actual value given could be Anything depending on what signal we give.
  • I chose to explicitly type the dict in dbus_progress_message because we know what the valid values are for this dict, we know that it should only ever have an int, float, or boolean as values (int/float for progress, int for count, and bool for the visibility indicators).
• Assigned the result of bus.send to _ to make it explicit that bus.send does return a value, but we don't capture it (this was flagged up by basedPyright). The bus.send cal returns a bool (I assume a success boolean). Ignoring this is something we might want to discuss for a couple of reasons.
  • Do we actually want to ignore this, or do we want to return a bool from these functions? Right now we don't consume any return at all when we call this so we'd have to move the _ = pattern up a level into the caller of this function, but it's up to you.
    • I would personally lean more into returning the bool from these functions but just ignoring it at the caller level, so that we have the return if we ever decide we want it (e.g. for unit tests)
  • Is this _ = ignore pattern we want to have in place across the codebase? I'm cautious of doing things just to appease a checker, but it can make it clear that a function is expected to return a value, but that we aren't using it.
  • I have no preference, and it's fine if we want to ignore the pattern for now and leave this for a discussion in Typing/Linting/"Quality Gates" in ProtonUp-Qt #417.

Just some general typing improvements with this one, motivated by a desire to write some form of test for dbusutil. It helps a lot to have good hinting for tests alone it feels like from my (albeit brief) experience, and usage and readability of course is also helped 😄

[DavidoTek]

Do we actually want to ignore this, or do we want to return a bool from these functions? Right now we don't consume any return at all when we call this so we'd have to move the _ = pattern up a level into the caller of this function, but it's up to you.
I would personally lean more into returning the bool from these functions but just ignoring it at the caller level, so that we have the return if we ever decide we want it (e.g. for unit tests)

return bus.send(message) seems appropriate. Feel free to add it here.

Is this _ = ignore pattern we want to have in place across the codebase? I'm cautious of doing things just to appease a checker, but it can make it clear that a function is expected to return a value, but that we aren't using it.

It makes sense to use when a function returns a tuple like _, apps = parse_appinfo(f, mapper=dict).
When the return value may be important, it could actually be desired that a checker notes this instead of drowning the warning. I'm open to this, #417 seems like a good place if there is anything to add.

[sonic2kk]

The functions now return bools. I also opted to use _ = when calling the functions for now just to be explicit, but in future we can decide if we want to keep this convention. The docstring for the functions also note that it returns a bool and what the bool represents. It's probably implied that it's a success boolean of some kind but it clarifies what success we're catching (the actual status given to us from sending the message to DBus).