[scd/isa] cleanup ISA repo implementation(s), notably IsaRepoV3

[Shastick]

The isaRepoV3 struct has the following comment:

// The purpose od isaRepoV3 is solely to support backwards compatibility
// It will be deleted from the codebase when all existing production deployments have been upgraded to 3.1.0+.

This means that we might be able to clean up some code. (Ie, identification_service_area_v3.go and possibly subcriptions_v3.go)

This implementation of the repo is used if the database schema has a version that is smaller than 4.0.0

@BenjaminPelletier the comment above was added approximately 4 years ago: how likely is it that all real-world deployments that still pull in the latest updates of the DSS would still run on an old schema?

Knowing whether or not to get rid of this older implementation is relevant for some work happening for #814

[BenjaminPelletier]

We can enforce the constraint of running with a database version of at least X by panicking on startup when the database version is older than X. After startup is successful, we know the database is not smaller than X. We can mostly do this whenever we want, except subject to some constraints:

1. There must be a smooth upgrade path. That is, we shouldn't go from release A having a max schema version of X to release B having a min schema version of X + 1 as it would be difficult to smoothly upgrade from release A to release B. Instead, either release A should tolerate a max schema version of X +1 (thereby requiring upgrade to schema X + 1 before upgrading to release B) or release B must tolerate a min schema version of X (thereby allowing upgrade to release B before upgrading to schema X + 1). And the constraint mentioned above is essentially enforcing/creating a minimum schema version.

2. Ideally, we want to make things as easy as practical for our users. The fewer migrations they are forced to make the better, as each migration requires additional operations resources. So, we should evaluate the tradeoff between improved product behavior and/or performance against the operations burden we place on users for migrations. But, I think this often comes out on the side of pushing the product behavior and/or performance forward, so I would expect it should be ok to enforce a minimum schema requirement for the next release as long as there is a smooth upgrade path (1 above)

3. Requirements and expectations must be clearly documented. When the minimum schema version changes, we must clearly document (ideally in every relevant place, but certainly in the release notes) the new requirements for the users/operators. Basically, in big bold letters somewhere we should say that schema must be migrated to at least Y before upgrading to release B if release B establishes a new minimum schema version of Y that wasn't present in release B - 1.