Attempt to limit remotely triggered resource exhaustion misbehaves.

[mdavidsaver]

cf. ControlSystemStudio/phoebus#3582

In an attempt to limit the ability of a client from triggering server-side resource exhaustion, I have a server connection stop read()ing from its socket while the send evbuffer is full. While this does limit creation of further subscriptions, it also limits destruction of subscriptions. The result is a kind of live-lock until the subscription rate is decreased, or the connection is closed.

[mdavidsaver]

I'm going to disable this feature as it has observed misbehavior, and no clearly demonstrated benefit.

[mdavidsaver]

With 4249885, the socket will always recv() and process. So, only subscription post will check tcp_tx_limit and make use of the backlog queue. For a well behaved client, this should be sufficient. This needs to be extended to GET/PUT/RPC/Introspect somehow to mitigate less than well behaved clients which eg. spam lots of concurrent GETs.

[mdavidsaver]

Since the PVA protocol design places no limits on the number of concurrent channel/operation in existence, and no practical way to predict reply size,, I don't think it will be possible to prevent a misbehaving client from trigger server resource exhaustion. This is also the case with CA, so not a practical regression.