Fix session tracker backwards compatibility.

[Joerger]

Forward port of #12728

This isn't strictly necessary, since v10 auth servers aren't expected to be fully compatible with v9 services (nodes, etc.), but it's an easy forward port and was requested.

[codingllama]

I'm not super familiar with event upload logic, so it's a bit hard to reason about the fact that all AccessDenied errors are safe to swallow.

Is it worth trying to put a test together for this situation?

What do we get by forward porting if it's not necessary? Could this have undesirable side-effects?

[Joerger]

I'm not super familiar with event upload logic, so it's a bit hard to reason about the fact that all AccessDenied errors are safe to swallow.

We expect to get NotFound from v8 and earlier v9 versions, and have the grace period backwards compatibility logic to handle this case -

teleport/lib/events/complete.go

Lines 158 to 161 in b780f0d

	// DELETE IN 11.0.0
	// To support v9/v8 versions which do not use SessionTrackerService,
	// sessions are only considered abandoned after the provided grace period.
	if u.cfg.GracePeriod != 0 {

With this change we are essentially handling AccessDenied errors in the same way, and defaulting to the grace period logic. So even if we got AccessDenied for another reason (although we never should), then we still have the grace period to fall back on.

Is it worth trying to put a test together for this situation?

Sure, I've added it to the grace period test.

What do we get by forward porting if it's not necessary? Could this have undesirable side-effects?

Although we don't formally support v9 auth with v10 db/app/desktop services, users still do it frequently enough that it would be better from a support standpoint handle fatal errors like this one, which returns an error for any session started with these services.

[codingllama]

Thanks for the explanation, Brian. Very helpful.