[proposal] Refactor identity provider object

This is a proposal on a breaking change to the way we represent identity providers to unblock IdP edits. I haven't thought through how this may be implemented in a backwards compatible way, but I wanted to open this to start some discussion.

Currently we store SAML identity provider connections as a single row which merges two configurations (service provider and identity provider config):

name
idp_metadata_document_string
idp_entity_id
sp_client_id
acs_url
slo_url
technical_contact_email
public_cert
private_key
group_attribute_name

This makes editing and updating IdP configuration bring in all of the concerns of what happens when we change identity sources (i.e. do we need an additional id along with external_id, do we perform merging, etc).

We can likely avoid these issues, while gaining a lot of the update benefits we want by splitting this in to two tables / objects, one that represents an identity provider and one that represents a service provider. This models the data closer to reality where the Silo is the service provider, and we then may have multiple IdPs that users could authenticate through (future state).

It would look something like:

Service Provider

name
sp_client_id
acs_url
slo_url
technical_contact_email
public_cert
private_key

Identity Provider

name <-- Not related to service provider name
idp_metadata_document_string
idp_entity_id
group_attribute_name

By splitting it this way we could support key / certificate rotations for signed requests, as well as changing sp_client_id and and technical_contact_email.

This also could help transition to a model where an Identity Provider can be deleted or edited (as long as there are no linked users) without touching the service provider configuration.

No files, tests, or entry points are named. Start by reviewing the current SAML identity-provider representation and the discussion about separating service-provider and identity-provider data. Done would require an agreed design and implementation plan covering edits, certificate rotations, and linked-user constraints.