Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

Some DBus types returned from dbus_message_get_args() require memory
to be released when done. We automatically attach these to the talloc
struct sbus_request memory context in this function.

This accepts varargs similar to dbus_message_get_args(), which are
rather awkward. However instead of reworking them completely, future
generated marshalling code will replace most uses of these varargs.

If parsing the dbus message fails, then it responds to the DBus caller
with an appropriate error such as o.f.D.Error.InvalidArgs. In these
cases (ie: when it returns FALSE) the sbus_request is finished.

Migrated some, but not all, uses of dbus_message_get_args() to the
new function. Some instances have uncommon semantics such as terminating
the connection upon failure to parse a message.

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

This starts a DBus server with some handlers, and runs some method
calls against it.

Note that we don't use the codegen in the sbus_tests, as we sorta
want to test this non-codegen related functionality on its own before
we run the sbus_codegen_tests.

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

Most importantly, stop using per connection private data. This doesn't
scale when you have more than one thing exporting or exported on a
connection.

Remove struct sbus_interface and expand sbus_conn_add_interface()
function. Remove various struct sbus_interface args to connection
initialization functions and make callers use sbus_conn_add_interface()
directly. The old method was optimized for exporting one interface
on a connection. We'll have connections that export zero, one or more
interfaces.

To export an interface on a DBus server, call sbus_conn_add_interface()
from within the sbus_server_conn_init_fn. To export an interface on
a DBus client, call sbus_conn_add_interface() after sbus_new_connection()
returns.

As before struct sbus_interface represents an object exported via DBus.
However it is now talloc allocated. One can set instance data on the
struct sbus_interface. This instance data is passed to the various
handlers and used in their implementation.

However, we now have type safe interface exporting in the various
high level sss_process_init() sss_monitor_init() and so on.

Introspection support was not in use, and is now gone until we
implement it using the metadata (future patch).

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

struct sbus_request represents a request from a dbus client
being handled by a dbus server implementation. The struct
contains the message, connection and method (and in the
future teh property) which is being requested.

In the future it will contain caller information as well.

sbus_request is a talloc memory context, and is a good place to
attach any allocations and memory specific to the request.

Each handler accepts an sbus_request. If a handler returns
EOK, it is assumed that the handler will finish the request.
Any of the sbus_request_*finish() methods can be used to
complete the request and send back a reply.

sbus_request_return_and_finish() uses the same argument
varargs syntax as dbus_message_append_args(), which isn't
a great syntax. Document it a bit, but don't try to redesign:
The marshalling work (will follow this patch set) will remove
the need to use varargs for most DBus implementation code.

This patch migrates the monitor and data provider dbus code
to use sbus_request, but does not try to rework the talloc
context's to use it.

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>