Do not block apt publishing if there is a more current pre-release

[wadells]

Summary

We do not publish pre-releases to apt repos, but we do publish them to github. That means we need to filter pre-releases out of the github release list when considering if an apt release should be published. We don't want v8.3.3 publishing to be blocked by v9.0.0-dev.1, only by v9.0.0.

Honestly, this is a bit of a mess, but it only needs to hold out a bit longer until #10746 lands.

Contributes to #10800

Testing Done

See the test case added.

before:

walt@work:~/git/teleport/build.assets/tooling$ go test ./...                                                                                                                                  
--- FAIL: TestCheckLatest (0.00s)                                                                                                                                                             
    --- FAIL: TestCheckLatest/pass-pre-release (0.00s)                                                                                                                                        
        require.go:794:                                                                                                                                                                       
                Error Trace:    main_test.go:121                                                                                                                                              
                Error:          Received unexpected error:                                                                                                                                    
                                found newer version of release, not releasing. Latest release: v9.0.0-beta.1, tag: v8.3.3                                                                     
                Test:           TestCheckLatest/pass-pre-release                                                                                                                              
FAIL                                                                                                                                                                                          
FAIL    github.com/gravitational/teleport/build.assets/tooling/cmd/check        0.003s                                                                                                        
ok      github.com/gravitational/teleport/build.assets/tooling/cmd/query-latest 0.003s                                                                                                        
?       github.com/gravitational/teleport/build.assets/tooling/cmd/render-tests [no test files]                                                                                               
?       github.com/gravitational/teleport/build.assets/tooling/lib/github       [no test files]                                                                                               
FAIL

after:

walt@work:~/git/teleport/build.assets/tooling$ go test ./...            
ok      github.com/gravitational/teleport/build.assets/tooling/cmd/check        0.004s
ok      github.com/gravitational/teleport/build.assets/tooling/cmd/query-latest (cached)
?       github.com/gravitational/teleport/build.assets/tooling/cmd/render-tests [no test files]
?       github.com/gravitational/teleport/build.assets/tooling/lib/github       [no test files]

[r0mant]

@wadells lgtm, do we have a way to test this somehow on a real pipeline or I guess we're gonna have to do another release?

[wadells]

@wadells lgtm, do we have a way to test this somehow on a real pipeline or I guess we're gonna have to do another release?

@r0mant Because this logic is in the very final promotion step, there isn't a great way to test it without running everything up to that point (and thus publishing artifacts).

What I've done in the past is strip out the actual publish steps (e.g. copy to s3 et al) and run the logic. For example, see the testing done here: #10295

I didn't think that was needed for this PR, as the added unit test covers the change in behavior.

Let me know what you're concerned about testing, and maybe I can suggest a way to test it out.