deprecate settings module

[jku]

We should aim to deprecate and remove the settings module

Some of the settings should not be exposed and AFAICT none of them should be global variables.

This is likely to be implemented piece by piece so the bug may just be a reminder to do that.

[jku]

The issue here is how to deprecate a global variable in a reasonable way?

variables cannot be deprecated (in the sense that using them would lead to a DeprecationWarning). We could workaround by replacing settings with an object in module import, and then giving deprecation warnings on property access... but I'm not sure the complexity is warranted here.

[joshuagl]

This might just be piecemeal as we implement new components during the rewrite and new code gradually moves away from tuf.settings. i.e. new client implementation has a new paradigm for constants and configurable settings.

See also secure-systems-lab/securesystemslib#219

[jku]

We have succeeded 🙏 ngclient does not import settings anymore

(to be clear: settings module still exists and is used in the legacy code. But Metadata API and ngclient do not use it and there's 0 reason for any repo-side tools to do that either)