chore: shared pipeline under same catalog with compatibility

[shuiyisong]

I hereby agree to the terms of the GreptimeDB CLA.

Refer to a related PR or issue link (optional)

What's changed and what's your intention?

As mentioned here, remove the schema in the pipeline information and cache key, so that all databases under the same catalog can access the shared pipelines.

Note: This is a breaking change. If the pipeline is already in use, check if pipelines have the same names but different schemas before upgrading.

Allow shared pipeline under the same catalog.

1. The newly created pipeline would be labeled under an empty string schema. Note, this would include the 'update' process, which means only the empty string schema is getting 'updated' or created.
2. The query of the pipeline would try to be as compatible as possible

cache

1. Try to find the pipeline labeled empty string schema, return if found.
2. Try to find the pipeline with the current schema, return if found.
3. Search all pipelines with the name and version suffix: if exactly one is found, return; else, throw an error.

database

1. Find all pipelines with the given name and version
2. If only one result is found, use the result
3. Check if there's an empty string schema result, use it if found
4. Check if there's a result labeled with the current schema, use it if found
5. Throw an error for multiple schema pipelines are found, but none of them is under the empty string schema and the current schema

PR Checklist

Please convert it to a draft if some of the following conditions are not met.

• I have written the necessary rustdoc comments.
• I have added the necessary unit tests and integration tests.
• This PR requires documentation updates.
• API changes are backward compatible.
• Schema or data changes are backward compatible.

[killme2008]

Note: This is a breaking change. If the pipeline is already in use, check if pipelines have the same names but different schemas before upgrading.

I am afraid some users already use it in this way. The breaking may not be acceptable.

[sunng87]

Is it possible to do it in a semi-compatible way:

• Always find pipeline by name
  • if there are pipelines with same name from different schema, use the pipeline of current schema
  • otherwise use the only pipeline returned (this is the breaking behaviour)
• Do not store schema for newly created pipeline so there won't be duplicated pipelines
• When updated existed pipeline, keep the schema name

[shuiyisong]

Is it possible to do it in a semi-compatible way:

* Always find pipeline by name
  
  * if there are pipelines with same name from different schema, use the pipeline of current schema
  * otherwise use the only pipeline returned (this is the breaking behaviour)

* Do not store schema for newly created pipeline so there won't be duplicated pipelines

* When updated existed pipeline, keep the schema name

There is one obscure case. If there are multiple pipelines with the same name but none of them is under the current schema.

This should be rare, we can throw an error if it occurs. Is this acceptable?

[sunng87]

This should be rare, we can throw an error if it occurs.

Sounds good.

[shuiyisong]

@sunng87 @killme2008 PTAL

[killme2008]

I wonder that the cloud catalog doesn't contain a public schema; how do we process it? @shuiyisong

[shuiyisong]

I wonder that the cloud catalog doesn't contain a public schema; how do we process it? @shuiyisong

This doesn't check the actual existence of the schema, which in this case is public. It's merely a string field in the greptime_private.pipelines.

[paomian]

Rest LGTM