Tablet Manager: Make WaitForPosition() accept either file:pos or GTID-based positions.

[PrismaPhonic]

This PR modifies WaitMasterPos which is ultimately called by WaitForPosition() such that WaitMasterPos() will respect the flavor of the GTIDSet in the supplied Position if that flavor is filePos. Previously, no matter what flavor the Position was, we always deferred to the flavor inherent to the connection grabbed from the Mysqld connection pool. This PR provides an essential update that allows WaitForPosition() to accept either file-based positions, or GTID based positions.

Related Issue: #6206

[shlomi-noach]

Is there a need to conn.Recycle()?

[PrismaPhonic]

For mysql.Connect there is no Recycle(). Recycle is a method available to a connection coming from a connection pool. In this case, we are making a direct connection to override the flavor.

[enisoc]

It sounds like this code is going away anyway, but for future reference, we would need to defer conn.Close() in this case.

[PrismaPhonic]

Refactored per @enisoc's suggestions. PTAL when you have the chance, thanks!

[shlomi-noach]

Merely a coding style comment, feel free to ignore. What I usually do is:

Suggested change

	if err != nil {
	return Position{}, err
	}
	return Position{
	GTIDSet: gtidSet,
	}, nil
	return Position{
	GTIDSet: gtidSet,
	}, err

it's the caller's responsibility to check if err != nil and if so, to ignore the GTIDSet value.

[PrismaPhonic]

I followed the pattern established in the rest of the codebase but you bring up a good point. I'm somewhat split on this. I agree with you that it's the caller's responsibility to check if err != nil but I'm also used to writing in languages where if a result is errorful, it's not even possible to access the successful result.

In this case though if err is not nil, then gtidSet would be nil anyway, so I think your version would actually return the same result with less code - and I like that. I suppose it's a question of how others feel regarding established patterns that already exist in the Vitess codebase, and if we should follow those patterns or break them when it's sensible? @enisoc @deepthi @systay @sougou?

[deepthi]

I prefer the less compact version because it is easier to read.

[deepthi]

LGTM