[Utils] Dynamic retryable function wrapper

[timgrein]

Closes https://github.com/elastic/enterprise-search-team/issues/4525

With the current @retryable decorator we're not able to set retries, retry_interval at runtime using fields as decorators are not dynamically updated at runtime. Therefore we need a wrapper function, which supports this behavior to support dynamic advanced configuration values for retrying.

Checklists

Pre-Review Checklist

• this PR has a meaningful title
• this PR links to all relevant github issues that it fixes or partially addresses
• if there is no GH issue, please create it. Each PR should have a link to an issue
• this PR has a thorough description
• Covered the changes with automated tests
• Tested the changes locally
• Added a label for each target release version (example: v7.13.2, v7.14.0, v8.0.0)
  - [ ] Considered corresponding documentation changes
  - [ ] Contributed any configuration settings changes to the configuration reference

[tarekziade]

why two distinct decorators? you can merge both and have both mechanism from with one single smart decorator

[timgrein]

why two distinct decorators? you can merge both and have both mechanism from with one single smart decorator

What do you mean by smart decorator? Is there an option in python to have a decorator, which supports something like this:

@retryable(retries=self.retries, ...)
def some_method()

Specifically referencing a field of an object, which can be updated during runtime. This PR adds a function wrapper, which is not a decorator AFAIU to support the behavior I've described above.

[tarekziade]

why two distinct decorators? you can merge both and have both mechanism from with one single smart decorator

What do you mean by smart decorator? Is there an option in python to have a decorator, which supports something like this:

@retryable(retries=self.retries, ...)
def some_method()

yeah the retryable function can have this signature :

def retryable(*args, **kw):
   if callable(args[0]):
       func =  args[0]
       etc..
   else:
      etc..

So you don't have two different decorators, it stays an internal implementation detail

[artem-shelkovnikov]

@timgrein should we close this PR or follow-up?