…nnection_established()

There is no conceivable reason why the creation of the D-Bus proxy
objects should fail, after we successfully got a D-Bus object.

Move the code out of the try-except block, which would hide errors.
This code should not fail, and if it would, we want to notice.

…tate

Only emit the signals that connection was established/lost, if
there is an actual change. In other words, make (some parts of)
_connection_{established,lost}() idempotent.

Also, drop comments like

        # connection established
        self._connection_established()

Clearing "dbus_obj" and "fw_policies" was forgotten, and "fw_helper" is
unused.

Also drop @handle_exceptions. This method is not supposed to throw
exceptions, and there is nothing to handle.

dbus.exceptions.DBusException does not always have a valid dbus_name. Check
for that, otherwise we get another exception while handling the exception.

… not running

When the daemon is not running, then bus.get_object() in
_connection_established() fails with a D-Bus exception
"org.freedesktop.DBus.Error.ServiceUnknown" and message "The name is not
activatable" (when using d-bus broker).

Consequently, self.dbus_obj and attributes like self.fw_properties are
left at None.

That means, if we call `firewall-cmd`, we get an attribute error and an
ugly backtrace:

  $ firewall-cmd
  Exception 'NoneType' object has no attribute 'Get'
  Error: Traceback (most recent call last):
    File "/usr/lib/python3.11/site-packages/firewall/client.py", line 50, in _impl
      return func(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^
    File "/usr/lib/python3.11/site-packages/firewall/client.py", line 3150, in get_property
      return dbus_to_python(self.fw_properties.Get(
                            ^^^^^^^^^^^^^^^^^^^^^^
  AttributeError: 'NoneType' object has no attribute 'Get'

Try to handle that case better by raising a better exception.

What we instead could do, is calling

  self.dbus_obj = self.bus.get_object(config.dbus.DBUS_INTERFACE,
                                      config.dbus.DBUS_PATH,
                                      follow_name_owner_changes=True)

then we would always be able to create D-Bus proxy objects.  However,
that affects the tracking of the well-known name, and I think we would
need to adjust our _connection_established() handling. It's not clear to
me, that that would really be preferable, at least not without further
changes.

Instead, add for attributes like `self.fw_properties` a getter
`self._get_fw_properties()`, which will raise a DBusException when the
proxy is None. Update most places that accessed the attribute to use the
new getter functions.

This gives:

  $ firewall-cmd
  Error: org.freedesktop.DBus.Error.NameHasNoOwner: firewalld is not running

Another benefit is, that you can catch DBusException when calling those
D-Bus methods, and don't need to consider that they might fail with an
AttributeError (which would indicate some internal bug).

This essentially allows to assert that what we request, has the expected
type.

The methods like FirewallClient.get_property() are decorated by @handle_exceptions.
Users (like `firewall-cmd`) hook into those exceptions and will abort the process.

Add FirewallClient.raw_*() helpers to access the underlying functionality.
When calling these, we can handle the exceptions ourselves.