Smoke tests

[mmacai]

• added Kafka consumer ready check utility function
• added smoke tests setup (with docker-compose & Elixir ExUnit)
• added smoke tests cases - proxy, kafka messaging, kafka ready check
• updated dependencies - had some weird problems with versions while running app/tests
• removed .dockerignore - unused => we are selectively picking files in Dockerfile anyway
• updated contribution guide

Test:

• mix test should work as before
• see contribution guide for steps how to run smoke tests (they should be sufficient to understand how to run them, if not steps should be updated!)

Closes #33

[kevinbader]

removed .dockerignore - unused => we are selectively picking files in Dockerfile anyway

do you think we should use .dockerignore instead?

[mmacai]

do you think we should use .dockerignore instead?

I read somewhere, that using .dockerignore is best practice and leads to less layers in images, so perhaps we can discuss it and leverage from it in new PR.

[kevinbader]

tab character ... typo?

[mmacai]

ye, that's a typo ... used to do automatic escaping of special characters from JS

[kevinbader]

Found one typo.. other than that it looks good to me

[kevinbader]

I get a compile-time warning:

==> rig_outbound_gateway
Compiling 7 files (.ex)
warning: definitions with multiple clauses and default values require a header. Instead of:

    def foo(:first_clause, b \\ :default) do ... end
    def foo(:second_clause, b) do ... end

one should write:

    def foo(a, b \\ :default)
    def foo(:first_clause, b) do ... end
    def foo(:second_clause, b) do ... end

def wait_for_consumer_ready/3 has multiple clauses and defines defaults in one or more clauses
  lib/rig_outbound_gateway/kafka/group_subscriber.ex:123

[kevinbader]

Instructions worked like charm, tests seem to work.

[kevinbader]

just a minor comment about the two specs: having one spec per function clause is optional and makes perfect sense if there something like "if I put a String.t in there, I get a String.t out, but if I put an atom in there, it'll be an atom" (you get the idea). However, in this case I feel it would be clearer (and less to write/read/maintain) to have just one combined spec, as I don't see any gain in expressing the same thing using two lines:

@spec wait_for_consumer_ready(String.t(), integer, integer) :: {:ok | :error, String.t()}

What do you think?

PS: I think integer here should actually be non_neg_integer() in both cases