Monorepo and Splitting Out To Different Packages

Goals

1. We've wanted to move to a monorepo for quite some time. This is so we can move the docs app out of the project for core components, and possible move things into our monorepo to ensure compatability — for example chrome tools or the eslint plugin.
2. We've discussed many times splitting Observable off to be a standalone package.
3. We may want to consider splitting rxjs/testing, rxjs/ajax, etc, off into their own packages as well.
4. We want to do this in the slowest, most easy to migrate to way possible.

Monorepo and multiple packages

• I think we should try to button up new feature work and the like for version 7 (which we are very close to doing, if we're not done already) and move to work on version 8 in earnest.
• In version 8, we'll keep the same exports (with regards to rxjs, rxjs/operators, rxjs/ajax, et al) but split all of those off into their own packages under @rxjs/observable, @rxjs/operators, @rxjs/ajax, etc. We'll want to bikeshed ideas like @rxjs/subjects or @rxjs/multicasting etc. There's a lot of ground to cover there, and I don't want to get bogged down on that in this discussion.
• In version 8 we're going to reexport from the new packages. For example, rxjs will export { Observable } from '@rxjs/observable'; etc.

Standalone Observable

• Moving away from lift: If we want a standalone Observable, we should move away from lift, because it requires too much knowledge of the inner working of RxJS in order to create custom operators that leverage it properly.
• We can start supporting Observable that doesn't have lift as a non-breaking change anytime. This is completely contained within our operate utility function now. We may even start supporting this in v7, as it should be completely innocuous. It's just a different call pattern. I actually have some work done around this, and everything looks solid.
• I think we're going to need to leave pipe on our standalone observable package, as it's central to our particular design for how to use RxJS. Even though pipe might not be immediately useful to users of Observable that don't care about operators. (libraries that export Observable, etc).

Long Term:

1. We wouldn't want to force people to move over to @rxjs/observable et al until version 9. That should be a long ways off.
2. Operator creation needs to be consumerized. We have our out internal way of creating operators, and we need to come up with a way of making that consumable and understandable to the masses. It has some advantages, like properly unsubscribing from firehose inner observables. (Currently it's impossible to do this properly with plan observer implementations) (A token/signal approach would help this)
3. Considerations around using abort signals, etc.

The issue names no files, tests, or concrete entry points. Start by mapping the current package and export layout against the proposed v8 re-exports for Observable, operators, ajax, and testing; done means an agreed migration design rather than a single code edit.