Trino Authentication types

[amommendes]

Is your feature request related to a problem? Please describe.
As Trino production deployments can have multiple authentication types, we could add a feature in the plugin to handle the authentication type feast will use.

Describe the solution you'd like
A flexible way to pass the authentication object to the plugin.
However, we need to decide if it would be better:
1 - To set the authentication type (and its properties) in the plugin configuration or the users need to pass an object auth

project: feature_store
registry: data/registry.db
provider: local
offline_store:
    type: feast_trino.trino.TrinoOfflineStore
    host: trino
    port: 8080
    catalog: hive
    dataset: feast
    connector:
        type: memory
        path: feast_trino.connector.memory
    auth:
        type: trino.auth.JWTAuthentication
        client_id: my-client-id
        issuer: http://my-issuer.com

In this case, we will need a class to handle the authentication flow to get the JWT token.

2 - We could requires from user to pass the authentication object when calling get_latest_features:

class TrinoOfflineStore(OfflineStore):
    ...
    @staticmethod
    def get_historical_features(
        config: RepoConfig,
        feature_views: List[FeatureView],
        feature_refs: List[str],
        entity_df: Union[pd.DataFrame, str],
        registry: Registry,
        project: str,
        full_feature_names: bool = False,
        auth: Authentication = None,
    ) -> TrinoRetrievalJob:
        if not isinstance(config.offline_store, TrinoOfflineStoreConfig):
            raise ValueError(
                "This function should be used with a TrinoOfflineStoreConfig object. Instead we have config.offline_store being '{type(config.offline_store)}'"
            )

        client = _get_trino_client(config=config, auth=auth)

...


from trino.auth import BasicAuthentication
auth = BasicAuthentication(username="foo", password="bar")
fs = FeatureStore(...)
fs.get_historical_features(..., auth=auth)

In the second case, we still need a way to handle authentication when calling the pull_latest_from_table_or_query through feast materialize, since feast cli does not have the info about connection if we do not have this in the plugin configuration