* Reuse the timeout for publishing to wait for a response.

* Added the confirm_timeout keyword argument.

If a timeout was specified and confirm_timeout was not use the timeout.
Otherwise, use the confirm_timeout.

* Fix unit test.

* Basic publish confirm timeout fix (#343)

* Reuse the timeout for publishing to wait for a response.

* Added the confirm_timeout keyword argument.

If a timeout was specified and confirm_timeout was not use the timeout.
Otherwise, use the confirm_timeout.

* Fix unit test.

* Add document for timeout and confirm_timeout in _basic_publish

Co-authored-by: Omer Katz <omer.drow@gmail.com>
Co-authored-by: Reza Shiri <rezashiri@cafebazaar.ir>

* Bump version to 2.6.2 for new release

Co-authored-by: Omer Katz <omer.drow@gmail.com>
Co-authored-by: RezaSi <rezashiri88@gmail.com>
Co-authored-by: Reza Shiri <rezashiri@cafebazaar.ir>
Co-authored-by: Carlos Corbacho <carlos.corbacho@complyadvantage.com>

Follow-up to https://github.com/celery/py-amqp/pull/328/, this removes an out of date comment.

`frame_writer` allocates a `bytearray` on intialization with a length based on the
`connection.frame_max` value. If `connection.frame_max` is changed to a larger value, this causes an
error like `pack_into requires a buffer of at least 408736 bytes`.

From what I can tell, `connection._on_tune` can arbitrarily change this value, although I'm not
totally sure in what cases it actually occurs.

For context, we're upgrading from Celery 3.1.25 -> Celery 4.1, librabbitmq 1.6.1 -> amqp 2.6.0,
kombo 3.0.37 -> 4.2.2.post1. This has worked fine in a small production environment, but fails on
our main deployment. The main culprit we see are lots of errors with `pack_into requires a buffer
of at least <x> bytes`, where x is always larger than our default `frame_max` of 131072. Despite
this, `bigbody` is False, which ends up with us attempting to write a frame that is too large into
the existing buffer. The only way I can see this happening is if `frame_max` increases.

AMQP 0.9.1 allows arbitrary data in long string fields.  However,
py-amqp assumed that the fields would always contain valid utf-8
data and would fail to deserialize messages with a property that
contained non-utf-8 data.

See #323