docs: add a best practices document

[Armenvardanyan95]

This is an initial version of a document describing best practices and antipatterns to avoid when using RxJS. This is a more finalized version of my draft, I tried to bring together important points mentioned by everyone in the related issue thread (#5185). Will be glad to hear how this can be improved

[Armenvardanyan95]

Important questions to be addressed:

• Do we need any more sections?
• Is the reason why subclassing is bad explained enough?
• Are the code examples okay?
• I did not update the navigation.json file, as I did not really know where should this go, if anyone directs me, I will also update that

WIll happily listen to everyone's thoughts

[cartant]

Maybe other core team members have an opinion as well

I don't think this could be merged without discussion. I don't agree with everything in this PR and, FWIW, I'm reluctant to declare a list of official best practices.

[CMCDragonkai]

Regarding the don't subclass section. Can you provide an alternative to this kind of usecase?

Suppose you had a domain class like KeyRing. The KeyRing is a class with properties and methods. You want the properties to be observable, and that's easy enough with third party observable decorators, but what if want the whole KeyRing object to be observable too?

Would that mean some sort of BehaviourSubject for the KeyRing object, so that downstream consumers can subscribe to the entire KeyRing and should get the pointer to the KeyRing object, and access all the changed properties atm.

One issue I'm thinking is that the KeyRing is a singleton object, it's not like new KeyRing is created on each change. That could meant it doesn't make sense for it to be a reactive class itself, but I'm not sure. There's not much information on whether it makes sense to subclass Observable with your own custom class, in which you want the whole domain object itself to be observable.