Notification Redesign in 4.5

<systemConfiguration>
    ...
    <!-- Proposed notification configuration, not conforming to 4.4 schema -->
    <notificationConfiguration> <!-- this is Container, but order of handlers inside does not matter -->
        <!-- Implementation notes for chained/forked -->
        <handler> <!-- changed to containerable in 4.5 -->
            <name>just for inf</name>
            <description>
                Describing the messy configuration below, what filters how, motivation, etc.
                Especially the motivation and goals.
            </description>
            <!--
            Top level filters in handler directly - they work, but the handler is consulted for all
            events, e.g. operations on non-interesting objects (like SysConfig for notifiers below).
            -->
            <category>modelEvent</category>
            <status>alsoSuccess</status>

            <!--
            Unclear whether this is forked or chained, it is executed by AggregatedEventHandler#processEvent,
            so it seems like chained, but AbstractGeneralNotifier#processEvent returns true (for common notifiers like those below), so it is effectively "forked" (although not parallel). -->
            <passwordResetNotifier> <!-- PasswordResetNotifierType extending from EventHandlerType -->
                <!--
                Even for simple notifiers the filters are processed by aggregatedEventHandler.processEvent
                called from AbstractGeneralNotifier#processEvent.
                -->
                <filterExpression>...</filterExpression>
                <!--
                What if the filters are only on <handler> element? This seems to be cleaner, but also means
                that these filters are consulted for all events - while concrete notifier uses "quick check" first.
                Also, many filters (e.g. operation) has more semantic meaning inside the notifier.
                -->
            </passwordResetNotifier>
            <!-- more concrete handlers -->
            <userPasswordNotifier>
                ...
            </userPasswordNotifier>
        </handler>

        <handler>
            <!-- Handler using messageExpression to call function library, returns Message -->
            <simpleUserNotifier>
                <!-- Creates the whole message object, also used for UI notification. -->
                <messageExpression>
                    <function>
                        <!--notifications-->
                        <libraryRef oid="a1fd1ad6-6dc6-40c9-87c8-2b8b2705f14f" type="FunctionLibraryType"/>
                        <name>simpleUserMessage</name>
                        <!-- Are params necessary? Shouldn't they be implicit here? -->
                        <parameter>
                            <name>event</name>
                            <expression>
                                <path>$event</path>
                            </expression>
                        </parameter>
                    </function>
                </messageExpression>
                <!-- This implies <transport>bar</transport> NOT implemented in 4.5 yet-->
                <transportConfig>
                    <name>bar</name>
                    <!-- Using different message function for bar transport. -->
                    <messageExpression>
                        <function>
                            <libraryRef oid="a1fd1ad6-6dc6-40c9-87c8-2b8b2705f14f" type="FunctionLibraryType"/>
                            <name>simpleUserMessageBar</name>
                            <!-- params, etc. -->
                        </function>
                    </messageExpression>
                    <!-- Things like logToFile overrides are probably overkill here. -->
                </transportConfig>
            </simpleUserNotifier>
        </handler>
        <handler>
            <customNotifier>
                <!-- Class implementing EventHandler. -->
                <type>com.example.midpoint.custom.CustomNotifierHandler</type>
            </customNotifier>
        </handler>
        <handler>
            <!--
            Currently one handler returns one recipient with potentially multiple addresses.
            Do we want to keep one recipient per handler (addresses are resolved in transport)?
            One recipient means one notification per event is generated by the handler.
            Multiple recipients means multiple notifications - but would they have the same text?
            -->
            <simpleWorkflowNotifier>
                <!--
                Currenlty "expressionFilter", but everything else is *Expression as well.
                NOT changing this right now, unless supporting both (but only one of them used at the same time).
                -->
                <filterExpression>
                    <script>
                        <code>event.requesteeIsUser()</code>
                    </script>
                </filterExpression>
                <!-- In 4.5 it is possible to return focus as well (or address as before). -->
                <recipientExpression>
                    <script>
                        <code>requestee</code>
                    </script>
                </recipientExpression>

                <!-- Template by reference -->
                <messageTemplateRef .../>

                <transport>mail</transport>
            </simpleWorkflowNotifier>
        </handler>

        <!--
        This section allows notification specific configuration for transports.
        Transports must still be declared in messageTransportConfiguration!
        -->
        <transportConfig>
            <name>mail</name>
            <logToFile>mail-notification.log</logToFile>
        </transportConfig>
        <transportConfig>
            <name>sms</name>
            <!-- not used by default -->
            <enabled>false</enabled>
            <!-- but furher configured if enabled per handler -->
            <redirectToFile>sms-notification.log</redirectToFile>
        </transportConfig>
    </notificationConfiguration>
    <messageTransportConfiguration>
        <mail>
            <!-- Unique name among all transports -->
            <name>mail</name>
            <server>
                <host>10.0.0.1</host>
                <port>25</port>
                <username>mail</username>
                <password>password</password>
            </server>
            <recipientAddressExpression>
                <!-- Here always called recipient; not what it was in notifier. -->
                <script><code>recipient.emailAddress</code></script>
            </recipientAddressExpression>
        </mail>
        <customTransport>
            <name>bar</name>
            <type>com.example.midpoint.custom.CustomBarTransport</type>
            <property>
                <key>url</key>
                <value>bar://10.0.0.47:1025/midpoint</value>
            </property>
            <!-- more properties... or, if we can support more fluid alternative: -->
            <properties>
                <url>bar://10.0.0.47:1025/midpoint</url>
                <!-- more properties with key in element name -->
            </properties>
            <recipientAddressExtractor>
                <script><code>recipient.telephoneNumber</code></script>
            </recipientAddressExtractor>
            <!-- All messages are redirected to file (e.g. transport not working yet). -->
            <redirectToFile>bar-messages.log</redirectToFile>
        </customTransport>
        <sms>
            <name>sms</name>
            <!-- more config -->
        </sms>
    </messageTransportConfiguration>
</systemConfiguration>

<handler>
    <chained>
        <operation>delete</operation>
    </chained>
    <chained>
        <simpleUserNotifier>
            <recipientExpression>
                <value>recipient@evolveum.com</value>
            </recipientExpression>
            <transport>dummy:simpleUserNotifier-DELETE</transport>
        </simpleUserNotifier>
    </chained>
</handler>

<handler>
    <simpleUserNotifier>
        <operation>delete</operation>
        <recipientExpression>
            <value>recipient@evolveum.com</value>
        </recipientExpression>
        <transport>dummy:simpleUserNotifier-DELETE</transport>
    </simpleUserNotifier>
</handler>