migrator: Use parsed command line flags already parsed by util.startup

migrator: Trick net.server into thinking the config is loaded Fixes "Loading outside Prosody or Prosody not yet initialized"

migrator: Customise startup sequence to fix #1673 (Thanks acidsys) Diverge from util.startup.prosodyctl() in order to skip unneeded behavior, such as loading the *Prosody* config file, which we do not need here, based on the `--config` flag which should point at the migrator config file instead. Notably removed: * read_config() since this loads the Prosody config * check_unwriteable() which checks logfiles specified in the Prosody config, so not relevant * make_dummy_hosts() but the migrator sets up its own hosts during migration

Fix various spelling errors (thanks codespell) Also special thanks to timeless, for wordlessly reminding me to check for typos.

mod_pubsub: Update configuration on reload (fixes #1382) Because of the way the previous pubsub service is carried access module reloads, it would retain the configuration options with their previous values from when the service was first created.

mod_pubsub: Silence warning about 'service' as argument [luacheck] Maybe the 'service' in the outer scope should be moved down to minimize overlap with other functions that receive the same service as argument?

mod_pep: Remove now unused util.cache import

util.pubsub: Signal that 'persistent-items' is unsupported when disabled XEP-0060 says that this the way to indicate that 'persistent-items' is unsupported, but doesn't explicitly say if it being disabled in the node configuration also counts as unsupported.

mod_pep: Remove use of RLU cache when persist_items was set to false This behavior came from some confusion over the meaning of persist_items. The correct behavior is that items are only stored when it is set to true. When set to false, the service becomes a "pure" publish-subscribe service, where items are forgotten immediately after broadcasting.

util.pubsub: Fix behavior of persist_items disabled When set to 'false' there is no need for a persistence interface at all, since items are not persisted after being broadcast. Had started wondering if maybe the behavior was wrong, after reading parts of XEP-0060 that pointed in that direction. Some discussion of this can be found in logs of xmpp:xsf@muc.xmpp.org?join from around 2021-07-20 Thanks to Ralph for confirming.