Add Support for TCPRoute API

[arkodg]

Description:
Add support for TCPRoute API defined here

Related #47

[arkodg]

we should wait on #413 which will refactor the provider before starting this issue

[danehans]

@arkodg this seems like a dupe of #47.

[arkodg]

@danehans I broke up #47 into individual issues and linked it back to #47 (one for TCP and other for UDP)

[Xunzhuo]

I am assigning myself, but if this is required #413, I think the finished time cannot be measured correctly. Not sure if this can be done in v0.3.0-rc1, but let us see the progress.

[arkodg]

@Xunzhuo suggest following the order mentioned here #641 (comment)
The work in IR and Xds Translator is already done thanks to @chauhanshubham , and probably just needs a test case :)

[youngnick]

Similarly to UDPRoute(#641), I think we need some design docs around the tradeoffs we'll need to make between transparent mode and proxy mode for TCP streams. The choice is basically between:

• transparent mode: client address available, routing changes required somehow to avoid return path check failure in transit.
• proxy mode: client address will appear to be the Envoy IP.

[arkodg]

@youngnick we are already using the the tcp_proxy filter for TLS Passthrough which works well, and envoy only supports proxy mode for TCP (docs are here) .
Imho this should unblock the implementation for TCPRoute in the Provider and Gateway API Translator.
To highlight this design decision of only supporting proxy mode for TCP, I can update the decision here. Are there any other considerations/decisions we should make before continuing with this implementation ?

[youngnick]

I think it's fine as long as we call out the limitation. I wouldn't be surprised if people end up wanting us to put in something about PROXY mode eventually, but that seems fine to me.