With this change, the sudo front-end will send an "accept" audit
event to the audit plugins after all the I/O logging plugins have
been initialized. This can be used by an audit plugin that does
not care about the result of the individual policy and approval
plugins and only wants to receive a single "accept" event if all
policy and approval plugins have succeeded. The plugin_type argument
for events sent by the front-end is SUDO_FRONT_END (0).
When converting sudo options from a dictionary to a tuple we need
to track the current index into the tuple separately from the
position of the dictionary entry.
so python log system can be used with sudo logsystem.
Loggers use it by default (the handler is set on the root logger).
If that is not the intent, it can be overridden explicitly.
Plugins can raise a sudo.PluginError exception to add context message
for the failure.
The callback's errstr gets filled up with the specified message.
But, as sudo expects a string constant (will not free the string),
we store it in the plugin context at least until next callback
invocation.
It is a bit more code, but it is more "pythonic" and easier to debug
as the enum values also know their names.
It is also an API break, eg. sudo.RC_OK becomes sudo.RC.OK as sudo.RC will
be the "type" of the enum, but I guess that is acceptable before the
initial release.
PyArg_ParseTuple sets the py_config_tuple pointer, but it does not
increment the reference count, so by decrementing, we end up freeing
the argument passed in.
Adapted the default sudo_printf from sudoers plugin to be able to print
errors before plugin open() gets called. (This is used by the multiple io
plugin loading to display error for too much plugin load.)
Since this makes us always have a sudo_log, I have removed the logic about
whether it is available or not.
