Enable server plugins to specify socket-option SO_LINGER

[daipom]

Which issue(s) this PR fixes:
None.

What this PR does / why we need it:
in_forward plugin has linger_timeout config, but most plugins using the server helper doesn't have the config, such as in_tcp or in_http.

The helper sets 0 to this option by default.
It causes the server to send RST rather than FIN on closing.
So this value needs to be changed if needing FIN signal on closing.

Adding this option to transport_config enables all plugins using the helper to change this value.

This fix makes linger_timeout config of in_forward plugin deprecated, but that config value can work as before.

Docs Changes:
Need.
fluent/fluentd-docs-gitbook#392

Release Note:
Need.

[daipom]

• Run Fluentd with the following config.

<source>
  @type tcp
  tag tcp.test
  <parse>
    @type regexp
    expression /^(?<field1>\d+):(?<field2>\w+)$/
  </parse>
</source>
<match tcp.*>
 @type stdout
</match>

• Run wireshark with the filter tcp.srcport == 5170 || tcp.dstport == 5170.
• Run the following command and create TCP connection.

$ nc 0.0.0.0 5170

• Stop Fluentd by pressing Ctrl+C.

Then we can confirm there is no FIN signal, but RST signal to close the connection.

With this fix, we can add linger_timeout to transport section as follows
and this enables the server to send FIN signal on closing.

<source>
  @type tcp
  tag tcp.test
  <parse>
    @type regexp
    expression /^(?<field1>\d+):(?<field2>\w+)$/
  </parse>
  <transport tcp>
    linger_timeout 1
  </transport>
</source>
<match tcp.*>
 @type stdout
</match>

[ashie]

Great! Thanks for the patch.
Adding it to transport section is reasonable.
In addition, this patch seems to keeps backward compatibility carefully:

• linger_timeout of in_forward still exists and marked as deprecated.
• The default linger_timeout for in_forward is kept as 0 (if a user doesn't set it, it will be set by server helper)

[ashie]

LGTM

TODO: Need to determine the target version (v1.4.6? v1.5.0?)

[ashie]

This patch keeps backward compatibility, and it seems to be at low risk of breaking existing features.
So I decide to merge it into next release (probably v1.14.6).

TODO: I think we need to determine & announce more systematic release cycle.

[daipom]

this patch seems to keeps backward compatibility

Yes, I have made this fix to keep backward compatibility.

Thanks for merging!