Consider limiting the lifetime of incoming socket connections

For sources where we accept relatively raw socket connections (e.g. tcp, syslog), we should consider limiting the lifetime of those incoming connections. Connections that live forever can complicate load balancing, shutdown, etc.

We currently have the functionality to close incoming tcp connections when shutdown is initiated (see here and here), and the implementation would be similar.

The primary challenge is to do this gracefully and in a way that minimizes the chance for data loss. None of these sources use protocols that allow for application-level acks, which means there's going to be a risk of missing data if we shut down the connection while the client thinks we're still connected and tries to send data. There are a few things we can do to try to minimize this:

1. Make the server-side reset a last resort by encouraging clients to regularly reopen connections (we can implement this on our sinks and document it for external clients)
2. Make the timeout as long as we feel is reasonable (e.g. 5 minutes)
3. Make the timeout adaptive, closing idle connections readily but busy ones only after waiting for them to go idle.

This also relates to #1429, since we want our sinks to react as quickly as possible when a server disconnects.

Start with the referenced sections of src/sources/util/tcp.rs that close incoming TCP connections during shutdown, then inspect the TCP and syslog source implementations. Review #1429 and the proposed fixed, client-driven, and adaptive timeout approaches; the scope is complete only once a graceful lifetime policy that minimizes data loss is agreed and implemented.