Tagging the new release

Tagging the new release

Bump client version to 5.3.0 (#634)

Also, bumped the version of the Hazelcast in couple of places
to 5.3.0.

DBAPI Docs [API-1972] (#626)

* Initial DBAPI docs, moved SQL to its own chapter.

* Added DBAPI sample

* updates

* Added DBAPI docs and code sample

* Fix ref

* Black

* Trivial doc fix

* Addressed reviews

* Addressed reviews

Tagging v5.1 release

[BACKPORT] Send TCP metrics for bytes sent and received to server (#500)

* Send TCP metrics for bytes sent and received to server

It would be good to send `tcp.bytesReceived` and `tcp.bytesSend`
metrics in the metrics blob to the server, so that, someone can
track how much traffic is passing between the server and the client.

I have manually tested the stats exported to Prometheus and verified
that these two new stats are displayed there correctly.

* add v5 to branch filter in test runner

Backport important fixes to 4.2.z (#498)

This is combined PR to backport some important changes that would
apply to 4.2.z. Mainly it fixes

- broken links
- test runners on Windows
- wrong `int_from_bytes` calculation

Get rid of the old links in the documentation (#489)

* Get rid of the old links in the documentation

We have now moved all our documentation & open-source site
to `hazelcast.com` with a new structure. This PR corrects all the
links to `*.hazelcast.org` with the new ones.

* add link checker option to sphinx and fix broken/redirected links

* use suggested article

Rename Fast-Aggregations to Aggregations (#460)

* Rename Fast-Aggregations to Aggregations

This request came during the release review process. To make
the client documentation more inline with the other documentation,
we are renaming `Fast Aggregations` to just `Aggregations`.

Also, improved the documentation a little bit for the Aggregations
section.

* make the text more clear

Fix `test_lifecycle_listener_receives_disconnected_event` (#417)

This test failed in Github Actions runners. The reason of the failure
is that, we try to check the received events right after shutting down
the member. It might be the case that, the member is shutdown, but
it is not visible to the client yet.

To tackle that, we now use `assertTrueEventually` to verify that
we receive the event.