Rework of direct memif

[Mixaster995]

Description

I think, it would be good to change current direct memif implementations.
Now there are excessive files creation in case of direct memif, but it causes issue in nse-composition networkservicemesh/deployments-k8s#2381
It might be better to just pass socket url up in chain without taking additional moves.

Current logic

1. On way back memif_3 created on client side of forwarder on the same file as memif_4
2. server-side of forwarder checking memif_3 existence and deleting memif_3 if it's present 3) server-side of forwarder not creating memif_2 and just passes memif_3 file url(same as memif_4) up in chain.
3. memif_1 created with memif_4 socket url

Suggestions

Rework steps 2,3:

• remove memif_3 creation on client-side of forwarder and pass socket url up in chain
• remove memif_3 check and deletion logic on server-side of forwarder and pass url to memif_1.

[edwarnicke]

@Mixaster995 Is this related to the memifproxy?

[edwarnicke]

@Mixaster995 Have we gotten to a root cause here?

[Mixaster995]

@edwarnicke well, not exactly - i've found half-root of this issue:
It is related to memif creation in vpp in case of direct memif scenario.
On refresh request up client hangs here - https://github.com/networkservicemesh/sdk-vpp/blob/main/pkg/networkservice/up/common.go#L100
I'm not sure what is the deep reason for this, but without unnecessary memif interface creation/deletion(current implementation) everything works fine.

A also added a comment in pr discussion, with details about changes i've made #377.

Please, share your thought about this proposed changes.