Repository: feast-dev/feast

Issue:
SqlRegistryConfig does not exist
## Expected Behavior 
When specifying "sql" as the registry type via the python SDK, feast uses the appropriate config class.
## Current Behavior
When specifying "sql" as the registry type via the python SDK, calling the FeatureStore object results in this error:
`feast.errors.FeastClassImportError: Could not import class 'SqlRegistryConfig' from module 'feast.infra.registry.sql'` 

`get_registry_config_from_type` builds the class name here: https://github.com/feast-dev/feast/blob/master/sdk/python/feast/repo_config.py#L499 causing the config to look for the `SqlRegistryConfig` class, which doesn't exist. This is due to the code adding `Config` to the end of the current registry class, which works when specifying "file" (which uses the `RegistryConfig` class, which exists), but not for "sql".

## Steps to reproduce
Set my_repo_config = RepoConfig(registry=RepoConfig(registry_type="sql")) and then call FeatureStore(config=my_repo_config), which will then result in the error described above.

### Specifications

- Version: 0.30.0
- Platform: Ubuntu
- Subsystem:

## Possible Solution
Option 1:
Change the `REGISTRY_CLASS_FOR_TYPE` dict so that "sql" maps to "feast.infra.registry.registry.Registry" instead of "feast.infra.registry.sql.SqlRegistry" - This may also have to be done for "snowflake.registry"

Option 2:
Create the `SqlRegistryConfig` class in `feast.infra.registry.sql`. I'm also not seeing a `SnowflakeRegistryConfig` class in the `feast.infra.registry.snowflake` module, so that may need to be created as well.

Option 3:
Alter the `get_registry_config_from_type` function so it builds out the class names differently based on they registry type
https://github.com/feast-dev/feast/blob/master/sdk/python/feast/repo_config.py#L499


Discussion:
From what I can see, there's already to type of pattern for loading the configuration class for a type.

Most of the config uses the class name to derive the config, except the feature server that uses a specific ENUM because of the `We do not support custom Feature Server` 
https://github.com/feast-dev/feast/blob/master/sdk/python/feast/repo_config.py#L535

Looking at this, I guess it's safe to say that we should create a `SqlRegistryConfig` class for the `SQLRegistry` class, to follow the other design pattern. At first, the `SQLRegistryConfig` would be as easy as being an extension of the Registry, then i required it can become more complex. 

I see that this bug priority is `p2`. Does that mean that it will be picked up ASAP? 

If you are ok with the plan, I think we can open a PR and propose a fix for this issue quite fast (it does seem to be a low-hanging fruit solution, that would work).
Maybe there's other concern that I don't grasp?

Edit: this still exists in version `0.30.2` 

Resolving patch:
diff --git a/sdk/python/feast/infra/registry/sql.py b/sdk/python/feast/infra/registry/sql.py
--- a/sdk/python/feast/infra/registry/sql.py
+++ b/sdk/python/feast/infra/registry/sql.py
@@ -5,6 +5,7 @@
 from threading import Lock
 from typing import Any, Callable, List, Optional, Set, Union
 
+from pydantic import StrictStr
 from sqlalchemy import (  # type: ignore
     BigInteger,
     Column,
@@ -178,10 +179,19 @@ class FeastMetadataKeys(Enum):
 )
 
 
+class SqlRegistryConfig(RegistryConfig):
+    registry_type: StrictStr = "sql"
+    """ str: Provider name or a class name that implements Registry."""
+
+    path: StrictStr = ""
+    """ str: Path to metadata store.
+    If registry_type is 'sql', then this is a database URL as expected by SQLAlchemy """
+
+
 class SqlRegistry(BaseRegistry):
     def __init__(
         self,
-        registry_config: Optional[RegistryConfig],
+        registry_config: Optional[Union[RegistryConfig, SqlRegistryConfig]],
         project: str,
         repo_path: Optional[Path],
     ):


Test patch: