+ The class provides mechanism to send and process
+ subscriptions and subscription deletes.
+
+ NOTE 1: It is currently unclear how an xAPP should identify a
+ subscription request/response pair uniquely in the absence/presence of
+ subscription manager. Ideally, the subscription manager should be
+ transperent to the xAPP but that may not be the case, i.e the
+ subscription manager may the subscription request id fields.
+ The xAPP needs to identify uniquely not just the subscription response, but
+ also when it needs to send a delete for the corresponding request.
+ From that perspective, the fields present in both the subscription response and
+ a delete request are the RICrequestId and RANfunctionId. However, the subscription manager
+ may require that the RICrequestId fields be set to a specific value (TBD). Hence
+ for current purposes, a RIC subscription request is uniquely identified by the
+ tuple <gNodeB-ID, RANfunctionId>. This is not ideal, since potentially the same RANfunctionID
+ may be subscribed to in different modes, but for now this is the constraint.
+
+
+ NOTE 2: There is discussion on tracking subscription request/repsonse using the RMR transaction ID.
+ However, a conscious choice made with the subscription_handler is that it be agnostic to the transmission
+ medium(RMR) for purposes of design isolation. Consequently, the subscription handler is not aware of any RMR
+ related semantics, but simply accepts a function to send the request/delete request that accepts a signature
+ Type, Length, Value . This also means in its current design, we cannot use transaction id to track request/response.
+
+
+ NOTE 3: The subscription handler is thread-safe, i.e multiple elements
+ can request subscriptions/subscription deletes from multiple threads. However
+ this does not preclude conflict if multiple threads are trying to make
+ subscriptions based on the same triplet (in which cases, results will be internally
+ consistent, but may yield errors to calling agent).