GKS Exporter: Use Cat-VRS and VRS

[korikuzma]

Right now, we're using a text-based Categorical Variant (no VRS Variation used). Ideally, we would like to move towards using VRS objects within the Categorical Variant

However, this would mean adding additional dependencies for VRS-Python Translator:

1. UTA - Postgres DB
2. SeqRepo - Sqlite DB + FASTA files

@susannasiebert @acoffman For ClinVar submissions via ClinVar-This, we would like to accept VRS objects and try to avoid the text-based Categorical Variants. I've switched this on the NCH side, but haven't gotten to the CIViC side yet. I'm not sure how this would work with your workflow - if these services would be spun up on the CIViC side or if you would be okay hitting a REST API where the versions of the data would be managed by the NCH team.

In MetaKB, we are doing this VRS translation, but I think moving that logic over here would be nice.

For example, this would look something like:

{
    "id": "civic.mpid:33",
    "type": "CategoricalVariant",
    "name": "EGFR L858R",
    "members": [
        {
            "id": "ga4gh:VA.pM_eD8ha-bnAu6wJOoQTtHYIvEShSN51",
            "type": "Allele",
            "name": "7-55259515-T-G",
            "location": {
                "id": "ga4gh:SL.7g6PIIHJ_QkKe_dRvkuCe8UtZCmPxo5B",
                "type": "SequenceLocation",
                "sequenceReference": {
                    "type": "SequenceReference",
                    "refgetAccession": "SQ.F-LrLMe1SRpfUZHkQmvkVKFEGaoDeHul"
                },
                "start": 55191821,
                "end": 55191822,
                "sequence": "T"
            },
            "state": {
                "type": "LiteralSequenceExpression",
                "sequence": "G"
            }
        },
        {
            "id": "ga4gh:VA.gV7_dnvF8SQSeUdvgDFhU65zK_csc6VE",
            "type": "Allele",
            "name": "NM_005228.4:c.2573T>G",
            "expressions": [
                {
                    "syntax": "hgvs.c",
                    "value": "NM_005228.4:c.2573T>G"
                }
            ],
            "location": {
                "id": "ga4gh:SL.LREsUiEYvOrRhwXW1rG72kXFPegvkNzI",
                "type": "SequenceLocation",
                "sequenceReference": {
                    "type": "SequenceReference",
                    "refgetAccession": "SQ.d_QsP29RWJi6bac7GOC9cJ9AO7s_HUMN"
                },
                "start": 2833,
                "end": 2834,
                "sequence": "T"
            },
            "state": {
                "type": "LiteralSequenceExpression",
                "sequence": "G"
            }
        }
    ],
    "constraints": [
        {
            "type": "DefiningAlleleConstraint",
            "allele": {
                "id": "ga4gh:VA.S41CcMJT2bcd8R4-qXZWH1PoHWNtG2PZ",
                "type": "Allele",
                "location": {
                    "id": "ga4gh:SL.v0_edynH98OIu-0QPVT5anCSOriAFSDQ",
                    "type": "SequenceLocation",
                    "sequenceReference": {
                        "type": "SequenceReference",
                        "refgetAccession": "SQ.vyo55F6mA6n2LgN4cagcdRzOuh38V4mE"
                    },
                    "start": 857,
                    "end": 858,
                    "sequence": "L"
                },
                "state": {
                    "type": "LiteralSequenceExpression",
                    "sequence": "R"
                }
            },
            "relations": [
                {
                    "primaryCoding": {
                        "system": "http://www.sequenceontology.org",
                        "code": "liftover_to"
                    }
                },
                {
                    "primaryCoding": {
                        "system": "http://www.sequenceontology.org",
                        "code": "translation_of"
                    }
                }
            ]
        }
    ]
}

[korikuzma]

This ticket should also remove the expressions extension

[korikuzma]

@susannasiebert in slack said she prefers hitting a rest API over spinning up our own services if that is an option.

Issue to talk with @ahwagner about is what REST API we want to use (AnyVar that exposes VRS-Python translation endpoints or Variation Normalizer). If we want to use the free-text variant name (such as BRAF V600E) we'll need to use the Variation Normalizer. If using HGVS or genomic coordinates, we could use other. Do we want to use canonical representation (where we use prioritized transcripts like MANE and liftover)? If so, we'll want to use the normalizer.

[korikuzma]

For now, we will migrate work from MetaKB transformer work that @jsstevenson has helped with (see https://github.com/cancervariants/metakb/blob/d65429fbcca5477f3199ab8742bc274e4555e3bf/server/src/metakb/transformers/civic.py#L328).

Will use the Variation Normalizer REST API

[jsstevenson]

For now, we will migrate work from MetaKB transformer work that @jsstevenson has helped with (see https://github.com/cancervariants/metakb/blob/d65429fbcca5477f3199ab8742bc274e4555e3bf/server/src/metakb/transformers/civic.py#L328).

Note that this is used by metakb for building a higher-order assertion around the CIViC MP, and wasn't designed as a substitute for the MP itself