vip, config: avoid multiple VIP owners exist at the same time

[djshow832]

What problem does this PR solve?

Issue Number: close #1117

Problem Summary:
When the client and the cluster are in different network segments, the client may fail to connect to the VIP after a VIP switch happens:

1. The new owner sends a GARP
2. The switch sends a who-has ARP to confirm the VIP
3. The old owner doesn't delete the VIP and both the owners respond to the switch
4. The switch may learn the old VIP owner
5. The switch caches the wrong owner for a long time
6. The client connects to the old owner and fails

What is changed and how it works:

• The old owner deletes the VIP and then resigns the owner
• The new owner refresh GARP for some time

Note:

• TiProxy doesn't guarantee always only one owner, such as TiProxy unexpected down, TiProxy cannot connect to PD. The new owner refreshes GARP to takeover the VIP with the best effort.
• This change will introduce a longer failover because there's a no-VIP window during the switchover.
• May need supporting VMAC in the future if the switch doesn't send who-has when the new owner sends a GARP.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Notable changes

• Has configuration change
• Has HTTP API interfaces change
• Has tiproxyctl change
• Other user behavior changes

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

- Fix VIP failover may leave upstream devices forwarding to the old owner by deleting the VIP before resigning ownership, removing intentional owner overlap, and refreshing GARP after takeover

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign yangkeao for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[codecov-commenter]

Codecov Report

❌ Patch coverage is 67.76316% with 49 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@30d5b3f). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
pkg/manager/vip/network.go	8.57%	32 Missing ⚠️
pkg/manager/elect/election.go	55.00%	9 Missing ⚠️
pkg/manager/vip/manager.go	93.82%	5 Missing ⚠️
lib/config/proxy.go	81.25%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1118   +/-   ##
=======================================
  Coverage        ?   67.19%           
=======================================
  Files           ?      144           
  Lines           ?    15176           
  Branches        ?        0           
=======================================
  Hits            ?    10197           
  Misses          ?     4288           
  Partials        ?      691           

Flag	Coverage Δ
unit	67.19% <67.76%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[djshow832]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4bfefbfbf2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Remove VIP before waiting for refresh worker

OnRetired waits for stopARPRefresh() before deleting the VIP. If the refresh goroutine is inside SendARP() (e.g. slow arping, non-zero burst interval, or command stall), retirement blocks while the VIP remains configured. The new owner can already acquire and bind the VIP once etcd ownership advances, so this ordering reintroduces a simultaneous-owner window that can repopulate upstream ARP caches with the old MAC.

Useful? React with 👍 / 👎.

[djshow832]

It will always cause the multi-vip problem if we only delete vip in onRetired(). However, the vip is also deleted before closing the election.