TxThrottler support for transactions outside BEGIN/COMMIT

[ejortegau]

Description

This change allows the TxThrottler to throttle requests sent outside of explicit transactions (i.e. explicit BEGIN/COMMIT blocks).

Related Issue(s)

#13037

Checklist

• "Backport to:" labels have been added if this change should be back-ported
• Tests were added or are not required
• Did the new or modified tests pass consistently locally and on the CI
• Documentation was added or is not required

Deployment Notes

Any existing deployments that use the transaction throttler (--enable-tx-throttler) will see it now throttle INSERT/UPDATE/DELETE instructions even if they are not inside of a BEGIN/COMMIT block. This changes the behavior with respect to previous versions.

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• If this is a change that users need to know about, please apply the release notes (needs details) label so that merging is blocked unless the summary release notes document is included.
• If a test is added or modified, there should be a documentation on top of the test to explain what the expected behavior is what the test does.

If a new flag is being introduced:

• Is it really necessary to add this flag?
• Flag names should be clear and intuitive (as far as possible)
• Help text should be descriptive.
• Flag names should use dashes (-) as word separators rather than underscores (_).

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow should be required, the maintainer team should be notified.

Bug fixes

• There should be at least one unit or end-to-end test.
• The Pull Request description should include a link to an issue that describes the bug.

Non-trivial changes

• There should be some code comments as to why things are implemented the way they are.

New/Existing features

• Should be documented, either by modifying the existing documentation or creating new documentation.
• New features should have a link to a feature request issue or an RFC that documents the use cases, corner cases and test cases.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• vtctl command output order should be stable and awk-able.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from VTop, if used there.

[harshit-gangal]

Let's decide how to proceed with the feature based on the comment here #13037

[harshit-gangal]

changes look good. It would need a few tests to validate the expectations.

[harshit-gangal]

Also, a good idea to update the release note in https://github.com/vitessio/vitess/blob/main/changelog/17.0/17.0.0/summary.md as it is changing the behaviour.

[harshit-gangal]

static check is failing

 go/vt/vttablet/tabletserver/query_executor_test.go:1807:2: S1023: redundant `return` statement (gosimple)
	return

[shlomi-noach]

LGTM with a minor styling request

[shlomi-noach]

A small nit: in vitess codebase we prefer early returns over indented conditions, so for example we'd do this:

Suggested change

	if options != nil && options.Priority != "" {
	if options == nil {
	return priority
	}
	if options.Priority == "" {
	return priority
	}

Mind that if you accept the above suggestion, the code will not compile as we need t remove a closing brace }