Inconsistent failure in the approval flow

[PrathibaJee]

When a new application gets approved, that application will be regarded to ALT, OKM, EATL, AA and OL respectively.
RO will first regard a newly approved application to ALT
ALT will

- retrieve the CC of the new application, 
- create links for the operation-servers (if links not available)
- create link between the server(new app) and client(old app) for the API "redirect-topology-change-information"
      ---- created link will be notified to OKM. Since OKM will not know the whereabouts of the new application, OKM will set the "default operation key" to the client.
- performs "redirect-topology-change-information" with the newly updated key
- ...
- ...

Then , RO will regard this application to OKM

OKM will

- regard the application in its configuration file
- create link between the server(new app) and client(old app) for the /v1/update-operation-key api
- If there is a failure in this link creation(reason : ALT took time to create the links)
- then OKM will unsubscribe(remove the fc-port but not the client stack) that application for operation key update.

Problem :
In such a scenario , OKM will first send, "OKM_MAXIMUM_WAIT_TIME_TO_RECEIVE_OPERATION_KEY_EXCEEDED"
If application is approved again , then ALT will send "RO_ALT_UNKNOWN"
After this, if the application is approved for n times, the result will be the same.

Reason for this failure :
In the above mentioned process , when ALT is first regarded with the new application ,
ALT will

- .....
- .....
 - create link between the server(new app) and client(old app) for the API "redirect-topology-change-information"
      ---- created link will be notified to OKM. Since OKM knows the whereabouts of the new application, OKM will set the new operation key to the client. But since the fc-port is not available, OKM could not able to set the operation key to the server.
- performs "redirect-topology-change-information" with the newly updated key which will fail resulting the "ALT_ALT_UNKNOWN" scenario.

WorkAround :
step1 : /v1/regard-application should be performed manually at the OKM application
step2 : application should be approved once again from the TAR UI.

Solution :
The criteria for sending the default operation key should also consider the existence of a subscription at the "LinkUpdateNotificationCausesOperationKeyUpdates" forwarding along with checking the http-client existence.