Don't reject replication set changes that change the DSN but point to the same database.

[tkaemming]

Right now, you can't really change a replication set's origin database DSN if it points to the same database. This could be really frustrating if you were trying to change the user or hostname but not actually moving the set, for instance.

[Fluxx]

So from reading this ticket and the code, the bug seems to be that, for example, if you changed the replication set configuration DSN (ReplicationSetConfiguration.database.dsn) to a new configuration, where the DSN resolved to the same physical host:

current_dsn = {'locahost'}
updated_dsn = {'127.0.0.1'}

additions = updated_dsn - current_dsn
deletion = current_dsn - updated_dsn

print additions
> {'127.0.0.1'}

print deletions
> {'locahost'}

The issue here is that 127.0.0.1 and localhost are actually the same host, so the configuration change is an update and not an addition and deletion.

In reading the code for what happens on additions, deletion, and updates, it seems that the end product of an addition and deletion vs an update (AFAICT) is functionally the same, it's just that old triggers are dropped and the new ones are added, which is unnecessary?