Deprecate kindAppOrSAMLIdPServiceProvider, AppServerOrSAMLIdPServiceProvider and use types.SAMLIdPServiceProvider

[flyinghermit]

Both the types.kindAppOrSAMLIdPServiceProvider and types.AppServerOrSAMLIdPServiceProvider types were used to show SAML service provider resources as "apps" in the UI and with server side pagination.

With unified resource view, these types are redundant + they demand unintended extra work if we want to apply granular resource level RBAC. Additionally, the AppServerOrSAMLIdPServiceProvider signature will be out of style pretty soon with the upcoming introduction of OIDC app.

This PR removes the usage of these types in the Web UI and instead uses types.SAMLIdPServiceProvider individually where needed. In the final unified resource list handler clusterUnifiedResourcesGet, the SAML resource are converted to App type so that the web UI side of implementation remains unchanged.

The notable changes includes:

• types.kindAppOrSAMLIdPServiceProvider and types.AppServerOrSAMLIdPServiceProvider are replaced with types.kindSAMLIdPServiceProvider and types.SAMLIdPServiceProvider.
• Protobuf message definitions for types.kindAppOrSAMLIdPServiceProvider and types.AppServerOrSAMLIdPServiceProvider are marked as deprecated.
• We already process types.AppServer separately and were double processing it with AppServerOrSAMLIdPServiceProvider. As such, there isn't anything new to be added to handle types.AppServer
• The test for clusterAppsGet is now updated to exclude SAML service provider type. It was meant to be already deleted in v15 but I have extended deletion TODO to v17.0.
• The unifiedresource for teleterm package is also updated but I've left the GetApps as is (they don't use the parent type anyway).

Manually tested with both Web UI and Connect app and verified by fetching both apps and SAML apps, along with other resources.

Breaking changes:
The changes in type are breaking for Connect, both when Auth Service is on higher version than Connect or vice versa.

The breaking change and backport plan for Connect is discussed separately in this ticket #39031

Deprecation and deletion:
Usage of types.kindAppOrSAMLIdPServiceProvider and types.AppServerOrSAMLIdPServiceProvider types are marked as DEPRECATED and scheduled to be deleted on v17, when both the Auth Service and the Connect will have been updated to handle correct types.

[github-actions]

The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with changelog: followed by the changelog entries for the PR.

[flyinghermit]

@ravicious @gzdunek, requested for your review as as well as this PR touches on teleterm package and also may have side effect to how apps and SAML apps have been fetched previously.

[avatus]

Code looks fine and from what I could test, the UI still works (unified resources, and access requests)

[gzdunek]

I did a quick pass and it looks good to me, on Monday I will be able to take a closer look (I'm off tomorrow).

[rudream]

LGTM and works with no issues

[flyinghermit]

@avatus @rudream @gzdunek would be great to have your review once again. To prevent Connect from breaking change, The PR as a whole will not be backported to v15. But selectively backport teleterm package so Connect will be ready to handle updated types when the changes are released in v16.

[gzdunek]

I tested it locally and seems to work fine.

But selectively backport teleterm package so Connect will be ready to handle updated types when the changes are released in v16.

What exactly do you want to backport to v15? AFAIK we don't have to backport anything, since the server side changes are already compatible with v15.

[flyinghermit]

What exactly do you want to backport to v15? AFAIK we don't have to backport anything, since the server side changes are already compatible with v15.

Chatting offline with @gzdunek but posting here for visibility. The backport is needed cause from v16, the Auth Service will only start responding with types.SAMLIdPServiceProvider type. In current v15 master, the teleterm package does not recognize this type. So if we do not backport teleterm package to v15, and unless the Auth Service and Connect are updated to v16 at the same time, Connect will not be able to handle types.SAMLIdPServiceProvider if Auth Service is on v16 and Connect is on v15 master.

Backporting teleterm package to v15 does not entirely solve the problem, but it will make the breaking change less aggressive as the v15 is still in its early phase and we can expect majority of the Connect users to be updated to latest v15.x by the time v16 is released.

[gzdunek]

@zmb3 could you look on this deprecation plan? My only concern is that the v15.x client will have to be updated to work with v16.0 server. OTOH, it seems to me that SAML apps are not a popular resource anyway, so it will not affect many users.

[gzdunek]

Zac suggested that we could detect the client version on the v16 server and then send a response compatible with v15 if needed.
Example: https://github.com/gravitational/teleport/pull/34667/files#diff-0d992726e983ecd7ccd935e9769652763907ad1a88ae462050d2770e557d3747R361

@flyinghermit what do you think?

[flyinghermit]

Zac suggested that we could detect the client version on the v16 server and then send a response compatible with v15 if needed.

@gzdunek That is another good option. I have created ticket to track this AppServerOrSAMLIdPServiceProvider type deprecation and backport plan for Connect so we have proper discussion planning for that.

Though I think it should not block this PR to get in right? cc @zmb3

[gzdunek]

Thanks @flyinghermit, from my side I think it is not blocking

[flyinghermit]

Thanks everyone for testing these changes. I am merging this PR now.