fix: Ensure neccesary fields are 64-bit aligned

[kurtisvg]

Change Description

Moves the Client.ConnectionsCounter field to the start of the struct since these values are guaranteed to be 64-bit aligned. Also adds a regression test to ensure that it doesn't get moved out of alignment in the future.

Checklist

• Make sure to open an issue as a
  bug/issue
  before writing your code! That way we can discuss the change, evaluate
  designs, and agree on the general idea.
• Ensure the tests and linter pass
• Appropriate documentation is updated (if necessary)

Relevant issues:

• Fixes bug: v1.19.0 x86-32 binaries segmentation violate on first connection #543

[kurtisvg]

@Carrotman42 PTAL if you have time

[Carrotman42]

I have a small criticism that usually one should put the more interesting (and more required) fields at the top of some struct, and have optional/uninteresting fields more toward the bottom. So putting this field up at the top of the struct seems wrong to me, especially since it seems like this field should never be set by users directly anyway. (see later when I suggest that we unexport it.)

If we are going to have a unit test anyway to verify that it's aligned appropriately, to me it seems better to leave the field be and just add padding until the test passes. I admit that's not ideal from a maintenance perspective, but if you're only ever tacking fields on to the end of the struct it won't require additional changes. Plus it's very easy to fix, just tedious.

Another option that I just thought of: the restriction applies only to 64 bit integers, so we can just change the type of this field to uint32. There's no way this proxy (or the Cloud SQL backend, or any database for that matter) is going to support more than 2^32 connections at the same time in any near future, that sounds just too high to be realistic especially given that each connection requires at least 4-6K of memory to maintain on this client Proxy side.

(and along with a type change, I think we should unexport that field by renaming it to connectionsCounter: it seems like a mistake to have exported it because we don't want outside callers to modify this field at all. If someone needs to read the current value, we can expose a getter for it.)

wydt?

[kurtisvg]

@Carrotman42 So I actually did consider switching it to uint32 instead for the same reasons you mentioned, but ended up dismissing that route because I wanted to avoid a breaking change. FWIW, I agree with you that it probably shouldn't have been exported, but at this point it's been like that for 3 years so unless I'm missing something it's pretty much stuck as is.

RE: Padding vs top of struct, padding the struct feels like a pretty hacky/unintuitive approach. If the only concern is signaling importance, it seems better to leave it at the top of the struct.

[Carrotman42]

I still disagree with the field placement but don't feel strongly enough :)

Lgtm, thanks for handling fixing this!