TCP keep alives for upstreams and downstream is mostly buried

[Nathan Fudenberg]

Version

main (1.17.x beta)

Describe the requested changes

Today we have a bare bones downstream keep alive doc that has been proven in many production environments. Particularly with aws. https://docs.solo.io/gloo-edge/latest/guides/integrations/aws/socket-options/ We should update this more thoroughly and modify our warning.
The follow on piece is that this gets confused and misplaced with regards to connections to the actual destinations (upstreams). The ability to set a keep alive there is hard to find as it is stored only on our proto docs which can often be confusing: https://docs.solo.io/gloo-edge/latest/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/connection.proto.sk/#connectionconfig https://docs.solo.io/gloo-edge/latest/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/upstream.proto.sk/

Link to any relevant existing docs

https://docs.solo.io/gloo-edge/latest/guides/integrations/aws/socket-options/

https://docs.solo.io/gloo-edge/latest/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/connection.proto.sk/#connectionconfig
https://docs.solo.io/gloo-edge/latest/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/upstream.proto.sk/

Browser Information

No response

Additional Context

Ideally upstream configuration for tcp keep alive should be well documented with an easy example.
Ideally both downstream and upstream docs are linked so that if there is confusion about one or both they can both be referenced.
Downstream connection is still very much a open format and can cause some issues such as trying to update the options on a running instance and we may want to codify those risks.

┆Issue is synchronized with this Asana task by Unito