async client support

[bshakur8]

Description

Add AsyncElasticsearch support.

Related Issue

#35

Type of Change

• 🚀 New feature (non-breaking change which adds functionality)

Checklist

• I've read the CODE_OF_CONDUCT.md document.
• I've read the CONTRIBUTING.md guide.
• I've updated the code style using make codestyle.
• I've written tests for all new methods and classes that I created.
• I've written the docstring in Google format for all the methods and classes that I used.

[bshakur8]

I know it's a duplicate code. My suggestion is to separate it to pre & post functions for each save, get and delete functions. Those pre&post function will be shared between ESModel and ESAsyncModel.
The only difference between them is that the later will use await in AsyncES client function.

For example:

def save(<args>)
    kwargs = pre_save(<args>)
    result = client.save(**kwargs)
    return post_save(result)
    
    
async def save(<args>)
    kwargs = pre_save(<args>)
    result = await client.save(**kwargs)
    return post_save(result)

@RamiAwar Do you agree with this approach or do you have a better one?

[RamiAwar]

Sorryy totally missed this! Will check

[RamiAwar]

Okay, here are my thoughts @bshakur8:

• The operation classes are a bit of an overkill - they make understanding the code much more complicated. Having a little bit of duplication is better if it makes maintenance and extendability easier. Maybe functions are a better alternative here. Maybe we can put the pre- and post- logic in functions that we'd then simply call in both clients.

• We should have 2 clients - an async one and a sync one. I don't like the idea of supporting sync and async operations on the same client as it's complicating something that should be simple. Users will either use the sync client, or they will use the async client, never both. Also every other ORM I've seen uses this same idea, so we shouldn't stray from the standard.

• The tests look amazing, the async logic looks solid. That's for that! We'll definitely merge that in as soon as we address the first two points.

What do you think? I'm willing to draft a more detailed suggestion if you want.