Adding support for mateName

[blankdots]

Description

This is a first attempt at dealing with mateName. It would be desirable in a response to get also the mate corresponding to the searched mateName, but as the specification is not clear on what should it contain, it is difficult to make guesses what should be in the response. (DONE)
yes also "alternateBases": "N[CHR10:121482216[", is not an alternate base.

The query in mate_name is quite verbose, and I am open to any suggestions to improve it.

Related issues

Fixes #56

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update (this needs a follow up PR) (DONE)

Changes Made

1. In init.sql there is a new beacon_mate_table that contains mate fusion specific fields
2. beacon.extensions.mate_name that contains a custom query for mate fusion
3. Modified JSON schema to support BND
4. Documentation update
5. version bump to prepare for release
6. unit tests

Testing

These queries should work:

• localhost:5050/query?referenceName=1&referenceBases=N&start=108796059&assemblyId=GRCh38&variantType=BND&end=121482216&datasetIds=urn:hg:1000genome&includeDatasetResponses=HIT
• localhost:5050/query?referenceName=1&referenceBases=N&start=108796059&assemblyId=GRCh38&mateName=10&end=121482216&datasetIds=urn:hg:1000genome&includeDatasetResponses=HIT
• localhost:5050/query?referenceName=1&referenceBases=N&startMin=108796058&startMax=108796059&assemblyId=GRCh38&mateName=10&endMin=121482215&endMax=121482216&datasetIds=urn:hg:1000genome&includeDatasetResponses=HIT

The response as of now is like:

{
    "beaconId": "localhost:5050",
    "apiVersion": "1.1.0",
    "exists": true,
    "alleleRequest": {
        "referenceName": "1",
        "referenceBases": "N",
        "assemblyId": "GRCh38",
        "includeDatasetResponses": "HIT",
        "datasetIds": [
            "urn:hg:1000genome"
        ],
        "startMin": 108796058,
        "startMax": 108796059,
        "endMin": 121482215,
        "endMax": 121482216
    },
    "datasetAlleleResponses": [
        {
            "datasetId": "urn:hg:1000genome",
            "referenceName": "1",
            "mateName": "10",
            "referenceID": "137_1",
            "mateID": "137_2",
            "mateStart": 121482216,
            "externalUrl": "ftp://data",
            "note": "Data.",
            "variantCount": 0,
            "callCount": 0,
            "sampleCount": 1,
            "frequency": 0,
            "exists": true,
            "referenceBases": "N",
            "alternateBases": "N[CHR10:121482216[",
            "variantType": "BND",
            "start": 108796058,
            "end": 108796059,
            "info": {
                "accessType": "PUBLIC"
            }
        },
        {
            "datasetId": "urn:hg:1000genome",
            "referenceName": "10",
            "mateName": "1",
            "referenceID": "137_2",
            "mateID": "137_1",
            "mateStart": 108796059,
            "externalUrl": "ftp://data",
            "note": "Data .",
            "variantCount": 0,
            "callCount": 0,
            "sampleCount": 1,
            "frequency": 0,
            "exists": true,
            "referenceBases": "N",
            "alternateBases": "]CHR1:108796059]N",
            "variantType": "BND",
            "start": 121482215,
            "end": 121482216,
            "info": {
                "accessType": "PUBLIC"
            }
        }
    ]
}

• Unit Tests - a few tests added so far (90% coverage)
• Needs testing (start an issue or do a follow up PR about it)

Why the db tests do not cover the full query?

That will be the job of integration tests, as soon as we will have a proper VCF mate fusion data.

Mentions

There will be a follow-up PR with docs and more tests.

Did this really require a new table?

It is a design decision to separate those mate fusion from the main data table, but also open to improvement suggestions.