Add warning on multi workers

[daipom]

This is a fix for #391.

[daipom]

This just fixes a warning log.
I don't have the environment, so I can't check the behavior.
However, I wrote test codes and checked all success of configure subtest.

[fujimotos]

I think the general direction of this patch is good. However:

So we need to add the same warning for the case of multi-workers.

Won't this implementation produce false-positives? For example, if we use multiple workers but put out_s3 in <worker 0>, that should be a perfectly fine way to use this plugin.

I'm thinking something like this:

<system>
  worker 3
</system>
<worker 0>
  <match **>
     @type s3
     ...
   </match>
</worker>

Nonetheless, this patch is likely to produce warnings on such cases, which I think can be confusing to users.

[daipom]

I think the general direction of this patch is good. However:

So we need to add the same warning for the case of multi-workers.

Won't this implementation produce false-positives? For example, if we use multiple workers but put out_s3 in <worker 0>, that should be a perfectly fine way to use this plugin.

I'm thinking something like this:

<system>
  worker 3
</system>
<worker 0>
  <match **>
     @type s3
     ...
   </match>
</worker>

Nonetheless, this patch is likely to produce warnings on such cases, which I think can be confusing to users.

In this case, system_config.workers is 1, so the warning is not produced.
(https://github.com/fluent/fluentd/blob/master/lib/fluent/plugin/base.rb#L61)

We should also have a test code for this case,
but I don't know how to specify the worker directive on the test code, so I can't do that right away.

[ashie]

BTW I've fixed CI failure which isn't concerned with this PR in #393

[daipom]

@ashie Thank you! I have rebased this branch and all checks have passed.

[fujimotos]

Merged via f55d70f, f5fa697, and bf8bb2c.

[daipom]

Thank you for reorganizing commits and merging!

[fujimotos]

Thank you for reorganizing commits and merging!

Background note on why I edited these commits:

One of truly awesome feature of Git is git bisect. It allows you to
perform biinary search on Git history to find a bad commit fast.

git-bisect - Use binary search to find the commit that introduced a bug

https://git-scm.com/docs/git-bisect

Now, to make git bisect actually usable, we need to keep master history
bisectable -- each commit should be non-breaking.

So while I understand that "test-first" camp people often intentionally
introduce a breaking commit (which I think is fine as a development
methodology), I'd rather keep the public tree bisectable. So I edited em.