…ryconnection-v1 to v2.66.0 (#3835)

…ryconnection-v1 to v2.66.0 (#3835)

🤖 I have created a release *beep* *boop*
---


<details><summary>2.59.2-SNAPSHOT</summary>

### Updating meta-information for bleeding-edge SNAPSHOT release.
</details>

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>

Aborted transactions should ideally be retried in the same transaction manager instance because the client library will ensure to populate the "Prev txn attempt's txn id" on retry (for mux sessions) which helps preserve the lock order(priority) of the transaction in scenarios of high contention thats causing txn wounding. This is achieved by using `resetForRetry()` that automatically takes care of preserving the lock order.

But if the customer application retries aborted transactions on a new TransactionManager instance with out using the `resetForRetry()`, we lose the lock order of the previous attempt.

To address this scenario of preserving the lockorder across transaction manger instance for a retry of the same transaction
Current proposal as per client lib team recommendation:
1. Overload the [Begin](https://togithub.com/googleapis/java-spanner/blob/702f5aa6468bb3f867032efabe685594359d79ae/google-cloud-spanner/src/main/java/com/google/cloud/spanner/TransactionManager.java#L62) API in the TransactionManager to accept an AbortedException argument.
2. Client library will populate the aborted transaction's transaction ID in the [AbortedException](https://togithub.com/googleapis/java-spanner/blob/877b165f2bacc52a3fb10fedf37ab02111b47a1e/google-cloud-spanner/src/main/java/com/google/cloud/spanner/AbortedException.java#L27) object which is propagated up the customer's application stack.
3. On the customer end, they will just need to pass in this AbortedException object to the "Begin" API when they retry the transaction on the new transaction manager instance.

Note: This will be a no-op for regular sessions.
b/407037309