Refactor `ctx`

[hacdias]

There is just one codebase that is run by one instance of the program at the time. Is it worth having a variable called ctx (context)? That'd certainly be more useful in HTTP (or any other protocol) handlers where each request is different.

While working on #1175 I found it a bit annoying to have to pass ctx around because I needed one single variable.

The idea is to remove ctx where possible and simply export the functions. Also, refactor the code so we don't have named and default exports on the same file as we do right now. That has been the cause for some bugs up until now.

[hacdias]

@lidel I was actually thinking about this now and searched to see if there was an issue about it. And guess what: there is. I think the code needs improvements here and there and there are certainly a lot of things that can be improved.

On my new PRs, I've been avoiding adding things to ctx as it is not really worth it and it just adds trouble.

[hacdias]

At the same time, we need to come up with a code layout that also avoid circular dependencies.

[SgtPooki]

I need to handle this in order to handle https://github.com/ipfs/ipfs-desktop/issues/1996

[SgtPooki]

@hacdias im going to be adding typings via jsdoc to ctx, and making it import/require-able

[SgtPooki]

@hacdias In order to understand what additional improvements should be made: What issues have you seen or ran into with ctx as it previously existed?

Does the PR I just pushed out (#2114) resolve those issues? What issues doesn't it resolve?

[TinyTb]

• ctx is an object that tries to implement an app context in ipfs-desktop. By refactoring it, we can speed up ipfs-desktop startup time.
• ctx being difficult to share & maintain has slowed development and caused "gotchas" for new features. #2378 fixes this.

[AliakbarETH]

Is this issue resolved or still pending?

[SgtPooki]

Still pending. I have a PR WIP where I cleaned up quite a bit, but I haven't returned to it for a while.