respondd: Issue with async data fetching

[mkg20001]

Currently babel uses some hack with threads in the constructor.
OLSR is currently using a segfaulty shared memory+fork approach.

None of this is sane and there needs to be a solution that solves this problem without too much impact.

Ideas:

• Every provider gets it's own process
  • Solves various issues, for ex global state with uloop
  • Hasn't been done previously because of resource limitations that are gone due to openwrt no longer supporting those devices
• Cache some providers
  • One idea is to run some providers on boot and others periodically
  • Either via cronjob and dump stuff in tmpfs so respondd just has to load stuff
  • Or providers expose if they are static (run once) or if they should be run periodically. This would be more effort on the respondd side but would make development of providers a lot simpler.
  • A solution in the middle would be adding that part to gluon.mk, so it automatically adds cron, etc. But again requires more work on the provider side.

Edit: Something that needs to be figured out is if a provider is using uloop themselves, how is this going to integrate with respondd? Or rather, which changes are needed so providers can actually hook the uloop properly.

[lemoer]

I am not sure about the actual overhead of processes in linux, but I would suppose that there is some overhead that we would introduce if we create a process for each provider. And I think respondd is already one of the most memory-intensive daemons we have. I remember some time ago, we moved away from using lua providers because of memory consumption.

However, I like the idea since it also tackles what was my goal with freifunk-gluon/packages#149. To regain some flexibility with respondd.