grpc-bridge example fails to get keys from the Python service

[drobertduke]

After getting docker-compose build to run using the #325 branch, I am able to set keys via the Python service but not get them

$> docker-compose exec python /client/client.py set foo bar
setf foo to bar

$> docker-compose exec python /client/client.py get foo
Traceback (most recent call last):
  File "/client/client.py", line 78, in <module>
    run()
  File "/client/client.py", line 57, in run
    response = client.get(key)
  File "/client/client.py", line 27, in get
    return kv.GetResponse().FromString(resp.content[5:])
  File "/usr/local/lib/python2.7/dist-packages/google/protobuf/internal/python_message.py", line 780, in FromString
    message.MergeFromString(s)
  File "/usr/local/lib/python2.7/dist-packages/google/protobuf/internal/python_message.py", line 1087, in MergeFromString
    if self._InternalParse(serialized, 0, length) != length:
  File "/usr/local/lib/python2.7/dist-packages/google/protobuf/internal/python_message.py", line 1113, in InternalParse
    new_pos = local_SkipField(buffer, new_pos, end, tag_bytes)
  File "/usr/local/lib/python2.7/dist-packages/google/protobuf/internal/decoder.py", line 850, in SkipField
    return WIRETYPE_TO_SKIPPER[wire_type](buffer, pos, end)
  File "/usr/local/lib/python2.7/dist-packages/google/protobuf/internal/decoder.py", line 820, in _RaiseInvalidWireType
    raise _DecodeError('Tag had invalid wire type.')
google.protobuf.message.DecodeError: Tag had invalid wire type.

Printing resp.content yields upstream connect error or disconnect/reset before headers

https://github.com/lyft/envoy/blob/master/source/common/router/router.cc#L383

It looks like the case is that the downstream response has started, but there's an upstream reset which is not a GlobalTimeout or a PerTryTimeout.

[mattklein123]

Related to #155. We need to automate building/testing the example containers.

[drobertduke]

I've confirmed that this happens because the tutorial instructions are out of order (you need to build the go service before building the containers), and the failure to start /usr/local/bin/srv is swallowed because it starts in the background.

[junr03]

fixed by #357