Enhance request/response abilities of net_response input plugin

Feature Request

An input plugin that can send multiple strings to a tcp connection while also reading the response of each action.

Proposal:

Create a new net_response_v2 input plugin to eventually replace net_response. Instead of using single values, it will accept a list of send and expect strings, and additionally add an expect_banner option and a send_on_failure option.

The expect_banner (if set) will be checked after the initial connection is made. The strings in the expect list will be checked immediately after any send string has been executed. If one of those expect strings is not found when expected the send_on_failure string will be sent if specified, otherwise the connection will be closed.

Questions

This seems like a good tactic so that new functionality can be introduced in a minor version change without impacting any existing uses and without complicating a single plugin to handle both conigurations, but I am not sure whether this adheres to any prior standard for plugin enhancements?

I would assume the v2 version is initially included in addition to the existing net_response plugin in a minor version update, but would entirely replace it on the next major version change?

Current behavior:

The net_response input plugin currently only allows for single send and expect to be set. If a response is received immediately after the connection is opened the expect string will be tested against that. If a send string is then executed there is no way to validate the output of that command.

Desired behavior:

The ability to execute any number of commands against a tcp connection while also validating their response.

Use cases:

SMTP

One example is to monitor the smtp protocol, where you want to verify the initial 220 code as well as the 250 and 221.

$ telnet mysmtptest.com 25

Trying mysmtptest.com...
Connected to mysmtptest.com.
Escape character is '^]'.
220 mysmtptest.com ESMTP Postfix

> ehlo me.com
250-mysmtptest.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

> quit
221 2.0.0 Bye

The plugin may be configured with the following parameters.

expect_banner = "220"
send = ["ehlo me.com", "quit"]
expect = ["250", "221"]
send_on_failure = "quit"

In this case if the 250 response is not seen after sending the ehlo command a quit will still be sent regardless in an attempt to cleanly close the connection. For this example it does not make much difference, but there may be cases where continuing to execute the send commands after a failure is seen is problematic.

FTP

Another is ensuring ftp connections closed out as expected, by verifying the initial 220 and the final 221.

$ telnet myftptest.com 21
Trying myftptest.com...
Connected to myftptest.com.
Escape character is '^]'.
220 Hello.

> quit
221 Goodbye.

The plugin may be configured with the following parameters.

expect_banner = "220"
send = ["quit"]
expect = ["221"]

Custom Services

and then of course there is any custom service that you may have running to accepts input and respond appropriately. These may or may not have an initial banner. In this example it connects with no banner, issues an info command, and expects to see a connected_clients string.

$ telnet mycustomerservice.com 3125
Trying mycustomerservice.com...
Connected to mycustomerservice.com.
Escape character is '^]'.

> info
connected_clients:18
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

The plugin may be configured with the following parameters.

send = ["info"]
expect = ["connected_clients"]