Rethink the AtConnection interface and replace current implementations with a Netty based solution

[akafredperry]

Is your feature request related to a problem? Please describe.

AtConnection Interface

• The command interface of AtConnection is synchronous, even though the underlying transport is async AND the interface exposed in the higher level API (AtClient) uses CompletableFutures. This feels wrong and mis-aligned with the underlying protocol.
• The AtConnection interface is tied to a socket implementation, this also feels wrong. An AtConnection should simply represent something that is capable of sending and receiving messages.

Current implementations of (AtConnectionBase, AtMonitorConnection, AtRootConnection, AtSecondaryConnection)

• Limited ability to recover from transient network failures and at server failover. Even if reconnect is set this will only attempt to reconnect once, when a command is executed. It is up to the caller to explicitly reconnect the connection after that.
• Reconnection is not thread-safe
• No command timeout (if the server blocks then the client blocks)
• An AtClientImpl with monitoring enabled will use 2 separate sockets
• The currently implementation is concerned with the underlying transport but also has some knowledge of the protocol.

Describe the solution you'd like

• Rewrite the AtConnection interface such that it is only concerned with sending commands and receiving responses and events (no transport specifics)
• Implement a TCP/Socket based solution using Netty that will work for interacting with the directory / root server and the at server. A single connection should be capable of supporting request / response and events (monitor)
• The implementation should support reconnect, re-resolution of endpoints, heartbeating
• Re-integrate the new implementation of AtConnection into AtClient and code that uses an AtConnection directly

Describe alternatives you've considered

No response

Additional context

No response