Should ElasticClient accept authentication settings?

[igor-vovk]

Documentation on credentials says that credentials should be passed manually to http clients through their own mechanisms of hooks. I did the same in http4s client https://github.com/Philippus/elastic4s/pull/3118, but now when I think about that, shouldn't ElasticClient provide a single unified mechanism by accepting credentials in a constructor argument? In tests it is implemented by overriding Executor, which also seems to be an anti-pattern. I don't see anything that prevents having single authentication mechanism on the level of ElasticClient. @Philippus WDYT?

We can provide 3 different authentication mechanisms (same way how it is implemented in http4s client):

• UsernamePassword, allowing to pass username, password parameters
• ApiKey, with apiKey parameter
• Obvious NoAuth that turns off authentication

ElasticSearch supports one more mechanism, which is temporary tokens, which I'd argue would be harder to implement as it requires building the logic of refreshing those tokens (and it is hard to implement manually with the current implementation). So I think it can be omitted, and support only 3 auth methods above.