feat(realtime): subscribe retry improvements

[grdsdev]

What kind of change does this PR introduce?

#742

What is the current behavior?

Channel doesn't have a limit for retrying, so it keeps retrying indefinitely, which causes a crash due the recursive call.

What is the new behavior?

Add a max retry attempt configuration (default to 5 attempts), along with a backoff + jitter delay calculation for the retry.

• Add a new method subscribeWithError() which throws a RealtimeError.maxRetryAttemptsReached or a CancellationError.
• Phase 1 (Current): Deprecate the subscribe() method in favor of the subscribeWithError()
• Phase 2 (Next Major Release): Rename subscribeWithError() back to subscribe() and remove the withError variant, it means the default will be the throwing method.

Additional context

Add any other context or screenshots.

[coveralls]

Pull Request Test Coverage Report for Build 16438495062

Details

• 99 of 105 (94.29%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.3%) to 76.944%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
Sources/Realtime/RealtimeChannelV2.swift	94	100	94.0%

Totals
Change from base Build 16421359102:	0.3%
Covered Lines:	5393
Relevant Lines:	7009

---

💛 - Coveralls

[o-santi]

There's some consideration on what await subscribe() should wait for exactly. @filipecabaco explained that both the broadcast and the presence parts should be considered as subscribed on the message acknoledgement success, which is what is currently being done:

supabase-swift/Sources/Realtime/RealtimeChannelV2.swift

Lines 281 to 289 in 8ac8c4a

	case .system:
	if message.status == .ok {
	logger?.debug("Subscribed to channel \(message.topic)")
	status = .subscribed
	} else {
	logger?.debug(
	"Failed to subscribe to channel \(message.topic): \(message.payload)"
	)
	}

but the postgres_changes part is only available when it receives the system message saying you're subscribed, which may take some time. This is already the current behavior, but maybe it is worth it adding this distinction in the RealtimeSubscribedStates, as a client may only be subscribed to broadcast, or presence or postgres_changes at any given time.