Validation has weakened in context of vendorization

[waxlamp]

For example, if you compare the DOI validation in schema version 0.6.0:

"doi": {
      "title": "DOI",
      "pattern": "^10.(48324|80507)/dandi\\.\\d{6}/\\d+\\.\\d+\\.\\d+",
      "readOnly": true,
      "nskey": "dandi",
      "type": "string"
}

with the same in version 0.7.0:

"doi": {
      "default": "",
      "nskey": "dandi",
      "pattern": "^(10\\.\\d{4,}/[a-z][-a-z]*\\.\\d{6}/\\d+\\.\\d+\\.\\d+|)$",
      "readOnly": true,
      "title": "DOI",
      "type": "string"
}

you can see that the validation moved from "has a valid structure and contains an allowed prefix" to just "has a valid structure". This is necessary to accommodate vendorization, since there is no longer a universal idea of "allowed prefix", but it also means that the validation for DOIs in a given deployment is now much weaker than it was before.

Questions:

1. Is this ok?
2. If it's not, what can we do about it?

In reference to question (2), some initial ideas:

• In a theoretical sense, what we might want is to parameterize the validation routine by including the vendorization variables. That is, instead of fetching a static schema and validating against that, we'd want to "fetch" a "function" that yields a proper "static" schema when supplied with the vendorization variables. In practice, this seems like a bad idea for a few reasons (e.g., we lose the utter simplicity of using published, static schema files).
• Could we instead layer validating against the static, generalized schema with a vendor-specific, Pydantic based validation? Is this something that is already done?

(Context: this came out of a discussion I had with @jjnesbitt about resolving dandi/dandi-archive#2687.)

[jjnesbitt]

Related: #367