El De-dog-lo

Given the multiprocessing bug likely rugs my initial approach, I will refactor to a delegated storage system where each read of something from `app.state.*` will trigger a call through a...

So given that distributed TaskIQ sequencing currently operates as multi-threading (and not multi-processing), this approach of worker-managed application state is okay as long as there isn't multiple workers trying to...

TODO: - [x] write documentation about `app.state` and how it gets used

> I still don't really understand why the datastore is on the worker side. Originally I don't think I actually understood what you were saying, but yes it is very...

> I still don't really understand why the datastore is on the worker side. I'm going to have to basically re-invent that whole thing for the platform side, more or...

Note for reviewers: `SILVERBACK_APP_NAME` changes to `SILVERBACK_BOT_NAME` from this PR, which also made some other larger changes for the whole `app` -> `bot` rewording Also need to publicize this, since...

One of the options would seem to be a config file of some sort. For ape core, one thing I want to do in 0.9 is allow config via pyproject.toml...

> I like the method @fubuloubu gave, but historically I've always used environment variables or a .env file to get pulled in and managed by pydantic settings. Then all of...

> Never really been a fan of the `.env` file pattern. Secret settings that override env vars in a hidden file that sometimes accidentally get committed to the repo isn't...

> We could even provide them individually. I think this requires a specific submodel to have it work, it doesn't work with a generic dict