enabled fieldalign in govet settings

[skoef]

As mentioned in #663 I enabled the fieldalignment linter in govet and aligned all mis-aligned structs. This was done mostly by using the fieldalignment tool and running it:

% go install golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest
% $GOPATH/bin/fieldalignment -fix ./canal

In some cases I had to make sure the comments (that fieldalignment doesn't take into account) were restored.

[atercattus]

Thank you for the efforts, fieldalign gives some interesting insights. But there is a fact that we need to respect maintainability and code readability too.

When rearranging fields, their logical grouping should be preserved.

We should not separate Host and Port fields here

	Host string
	Port uint16

VS

	Host string
	// a lot of strings ...
	Port uint16

The same goes for Tables+TablesDB and Tables+Databases here.
They should be near each other.

	// Will override Databases
	Tables  []string
	TableDB string

	Databases []string

VS

	TableDB string
	// ...
	Databases    []string
	ExtraOptions []string

	// Will override Databases
	Tables []string

And another example is a mutex field that is bundled with fields it protects here

	synchro struct {
		sync.Mutex
		// other fields
	}

VS

	synchro struct {
		// other fields
		sync.Mutex
		// other fields
	}

There are more examples, but I think 3 is enough to demonstrate the principle.

So, let's use fieldalign only when it doesn't break the code readability?

[skoef]

While converting certain structs I already imagined comments like this. I completely get the readability aspect, I will see if I can ignore the linter on specific structs that benefit from certain order in parameters.

[atercattus]

Could you keep stmts and stmtID near each other?

[skoef]

While the config of binlog parsing shouldn't really put a hit on the memory usage when it isn't optimally aligned, especially server.Conn and client.Conn can make a real change in memory usage in a connection hungry application. I'd say this is the one struct you'd want to align as best as possible. I can add comments on what each field represents, perhaps that is the right middle ground?

[skoef]

@atercattus what is your opinion about this?

[lance6716]

I'm neutral to this PR 😄

[skoef]

let's just leave this as is for now