[Housekeeping] Refactor flyteadmin config handling

[katrogan]

Describe the issue

The entire flyteadmin config handling, in the (note) poorly-named runtime folder is unnecessarily convoluted. Every top-level config block is accessed by a provider, which is an instance of an interface that is all injected as a singleton in the root service and makes the mockability of limited usefulness.

We should just abandon this complexity altogether. Define a config, call GetConfig in one place, and pass along config structs where necessary, instead of the providers, to preserve ease of unit testing.

What if we do not do this?

Adding new config fields continues to stay tedious, new contributors to flyteadmin will be rightfully confused and excess code/unnecessary abstractions usually slows down velocity

Related component(s)

flyteadmin

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes

[github-actions]

Hello 👋, This issue has been inactive for over 9 months. To help maintain a clean and focused backlog, we'll be marking this issue as stale and will close the issue if we detect no activity in the next 7 days. Thank you for your contribution and understanding! 🙏

[katrogan]

(fighting the stalebot) we should keep this open :)

[github-actions]

Hello 👋, this issue has been inactive for over 9 months. To help maintain a clean and focused backlog, we'll be marking this issue as stale and will engage on it to decide if it is still applicable.
Thank you for your contribution and understanding! 🙏

[katrogan]

back here to counteract stalebot