chore(payment processor): remove stream payment

[benjlevesque]

experiment to see the impact of the sf sdk

[MantisClone]

What would motivate us to remove stream payments?

[benjlevesque]

@MantisClone the rn library has way too many dependencies, we need to rethink its architecture I believe.

From the top of my mind, some of the issues:

• it's very heavy, causing issues for Frontend use
• importing the library has an important impact on process startup (very visible on unit tests)
• the dependencies are chaotic, we can't upgrade one without breaking 10 others

I believe the payment packages (detection and processor) should be split per ecosystem (NEAR, EVM...) / vendor (SF) /... and injected into the Request client instead having them loaded by default . Alternatively we could dynamically load them but that's less flexible.

This would enable having a dapp that only does evm payments without loading the whole mess, or having apps / backend focusing on non-payment parts.

The superfluid SDK isn't directly responsible, I'm simply trying to see more clearly the state of our dependencies

[MantisClone]

@skiv71 and I agree that the dependencies are a mess. Thank you, @benjlevesque, for taking the time to look into it more deeply! :pray: I'm definitely open to refactoring to reduce coupling between packages. :+1: I hesitate to remove streaming entirely :thinking:

[benjlevesque]

closing, not absolutely required. This was an experiment. Feel free to re-open if it's needed