WIP: Outbound flow mapper

[andreskrey]

Initial approach to a self service framework. The final form would be a fully fledged UI that would allow users to drag and drop flows and edit mappings.

For this initial phase, only the outbound flows will be exported, as the inbound ones are managed by the api-bundle and coupled by camel config.

New components added:

• A simple flow exporter command to simplify access to the new exporter. smartesb:flows:export Exporter functionality should not be placed here, as eventually this project should be called from a browser, rather than a command.
• IsConfigurableService trait got a new function called getMethodsConfiguration that will return the method configuration. Method in this context is what defines what API in the target system should be called and what payload should be sent. We already had a setter for this property, this getter will return what the setter... sets. Given that this is internal configuration to the Producer, it was the most sensible place to put it, instead of hijacking this information while the container is built.
• Producers are tagged at built time, in order to get them all together when building the flow export. Tag name is smartesb.producer, defined in the constant PRODUCER_TAG.
• The flow exporter itself, explained below.

Flow exporter

The flow exporter introduces:

• The flow exporter itself, which acts as a AbstractWebServiceProducer, getting all the steps, hijacking the definition and running the "request" ones. It uses all the traits that the Producers already use, and it's configured in a similar way. The reason behind this is to take advantage of how strings are evaluated (for example, how we prepend eval to each mapping, which is a custom keyword that Symfony's evaluator doesn't support.
• The Unmapper, which is a fake mapper that will simple return the mappings that it knows about. Remember that, although the YML producer configuration holds the mapping information, this producer ignores each mapping as this is passed to the Mapper at built time. Unmapper gets the same information as Mapper, but instead of mapping, it just returns the mapping definition
• ProducerMethod and ProducerMapping, DTOs to handle all the information collected in a OO way

How to test

Declare this branch as a dev-dependency of your ESB and run php bin/console smartesb:flows:export. This command for now assumes the name of the producer (I'm leaking a bit of information about Smartbox here :F ). You should see all the methods of the producer and the mappings calculated.

Challenges

• FlowExporter gets the producers directly from the container. It gets injected the name of the producer and when building flows, it calls the container. This should be replaced with a service subscription but it's outside the scope of this ticket.
• Submappings (Flow uses mapping A -> mapping A uses mapping B) are not calculated right now. It will simply return eval: mapper.map(context, other_mapping). This tricky part around this is how to detect when a string is a simple mapping, and when a string is a submapping. Feeding it back to the string evaluator doesn't work because it will complain about the missing piece of information (context in the example)
• SOAP is not supported right now (REST uses the key body, SOAP uses the key parameters)
• *.get definitions are going to be specially tricky to emulate, as they expect an object. For example, your flow requires body.get('my-field-in-the-body-request'). This currently fails with the error Could not evaluate 'body.get('voucherId')'. Variable "body" is not valid around position 1 for expression... because body is passed to the evaluator with all the information in the nromal flow of the application, but here body is not defined anywhere and it can be very tricky to guess what needs to be passed. This of course is outside the scope of this ticket, as we are doing outbound mappings for now, but nonetheless the command will fail in these situations.
• In the part where the FlowExporter gets the body, it checks if it is a string or if it is an array. If it is a string, it passes the string as it is to the evaluator. If it is an array, it gets the first item. This will be a problem on other flows that use "body" as a collection of single items (internal to SBX, get voucher detials for example), as this is defined as an array. I'm not sure how this is managed by the real evaluator, given that it only accepts strings.
• SF2.8 compatibility fails right now but it's an easy fix.