Problematic Error Handling in Subscribed Indication Stream

[ty3gx]

Issue Summary:
I've encountered an issue with the error handling in the subscribed indication stream, specifically in the Subscribe function implementation. The problem occurs when the stream encounters an error that is not a result of context cancellation, timeout, or EOF. The implementation here tries to log the error and then read again from the stream. However, according to the gRPC implementation of streams, any error (other than EOF) results in the stream being aborted. Then continuously reading from this aborted stream leads to repeated processing of the same error, and no acceptance of the subsequent messages.

Steps to Reproduce:

1. Trigger a condition that causes an error in the indication stream (other than context cancellation, timeout, or EOF). For example, send a malformed ASN.1 indication message from the RAN node, to trigger a decode error in E2T.
2. Observe the behavior of the xApp using the Subscribe function when trying to read from the affected stream.

Observed Behavior:

1. The stream fails to process subsequent well-formed indication messages after encountering an error.
2. The xApp is flooded with repetitive error messages resulting from a single decoding error of a malformed indication message.
3. The connected RAN node does not receive any feedback on the error in the stream.
4. The error persists indefinitely, effectively breaking the stream from the RAN to the affected xApp. The only resolution is to re-initialize the subscribe procedure by either restarting the xApp or the RAN.

Expected Behavior:
Ideally, the E2T should report the malformed message back to the RAN and avoid propagating the error to the xApp. Alternatively, the xApp should have the capability to rebuild the affected stream to recover from the error. At the very least, the RAN should receive some form of error notification.

Impact:
This issue significantly affects the reliability and robustness of all xApps using the SDK, as a single malformed indication message can disrupt the entire indication stream, affecting both the xApp's communication with the connected RAN node.

Please let me know if there are any inaccuracies in my analysis or if additional information is needed. Any discussion of the issue or potential solutions is also welcome. Thanks!