feat: refactor persistent term usage to behaviour

[Ziinc]

This PR adds in an ETS configuration storage option, for #342 .

Our use case has many dynamically-created Broadway servers (each with different non-static names). This results in global GC getting triggered. Although fb69a7a has some improvements, it is insufficient for our situation.

If we were to continue using persistent term using the above mentioned change, it will result in large buildup in the hash table over time. As time to update/store the term is proportional to hash table size, resulting in degrading storage speeds over time. In our case, the memory buildup over time may also be non-negligible.

However, without the above change (where the persistent term is not cleaned up), it will result in the GC getting triggered each time the server goes down (due to our autoscaling logic).

Switching over to :ets based storage would avoid the GC-ing issues.

[josevalim]

Thank you! Although I don't think we need modules and behaviours. A simple :config_storate with either :persistent_term or :ets is enough. :)

[Ziinc]

👍 i've switched it to atom-based config, and moved the docs out of each module. Also removed the module docs for those to keep them internal. It is technically possible for users to pass in their own custom module as an option, just leaving that option open but undocumented.

[josevalim]

💚 💙 💜 💛 ❤️

[starbelly]

Hey @josevalim @wojtekmach and other maintainers. Could a release be cut ? Really need this feature per dynamic starts and stops in our system and the just the right configuration to cause literal area gc pressure 😄

[josevalim]

v1.2.0 is out.