[SPIKE] Investigate ingestion of significant vulnerability data into ClickHouse

As a follow up to #352665 (closed), we should to investigate the engineering complexity of ingesting significant quantities of vulnerability data into ClickHouse, parsing it and ensuring that ClickHouse remains functional and performant with our strategy of doing this as a potential alternative solution to ElasticSearch for metric aggregation and near-real-time querying.

Expected Outcomes

1. Determine the engineering complexity involved in vulnerability ingestion into ClickHouse. Some questions to consider:
   1. Does ClickHouse have an API we want to push vulnerability information into one at a time, or in bulk?
   2. Do we need to write to a file and ingest that into ClickHouse some different way?
   3. What is the way GitLab currently ingests issue data into ClickHouse for the Advanced Search capability, and can we mimic it?
   4. If the data needs to be ingested asynchronously, what kind of delays should we expect?
2. Investigate the costs related to our use of ClickHouse.
   1. What is our expected data domain size in ClickHouse? What kind of cost impact might this have on GitLab.com? (Bearing in mind we do already have an ClickHouse deployment)
3. What will the impact be on our self-managed users?
   1. What kind of resources will be needed to run a ClickHouse instance?
   2. What sort of administrative complexity would this incur on our self-managed users?
   3. What complexity would be involved in making this behaviour opt-in?

Timebox: 4 Days