feat: Extend get_feature_view to return stream and on demand feature views

[tokoko]

Which issue(s) this PR fixes:

• Fixes Registry get_feature_view should read stream and on-demand feature views #4235

[tokoko]

@dmartinol Ended up having to make changes all over. Maybe you can find time to look through.

[dmartinol]

lgtm.
I just see a lot of assert isinstance(fv, FeatureView) that I hope are all correct as some of them, like the OnDemandFV, are only BaseFV instead. I cannot follow the complete flow, but I trust you 👍

[tokoko]

That's mostly to accommodate the linter for now, I should probably add more feast-specific exceptions (for example if a user is asking to materialize an odfv, which doesn't make sense)

On a general note, I found that we have a following trade-off here:

• When get_feature_view returns all types a lot of most common operations become cleaner to implement, for example when a user is passing a list of fv names that might be any one of them, we no longer need crazy exception handling to figure out which method to call.
• In some other less common cases when only a single fv type makes sense, we will now have to check the type of the object returned, we can no longer rely on the fact that registry method used would do that for us. When we drop py3.9, we should probably start using python match statements for this.

Despite the trade-off, I still think it's a worthwhile change. Still wanted to get your opinion.

[dmartinol]

utils._list_feature_views has a similar logic but misses the isinstance check, don't we need it there too?

[tokoko]

Not yet, it's using list_feature_views to get the objects which is still FeatureView specific, this PR only makes changes to get_feature_view. I'll do that in a follow-up.

[dmartinol]

the method is declared to return a FeatureView, isn't the linter complaining about that?
I think the reason is that OnDemandFeatureView.from_proto does not declare the retuned type 😉

[dmartinol]

• In some other less common cases when only a single fv type makes sense, we will now have to check the type of the object returned, we can no longer rely on the fact that registry method used would do that for us. When we drop py3.9, we should probably start using python match statements for

It we really have this need, can't we apply an optional filter to return only instances of the requested type with no need to further check?
Really pseudo-code:

fv :  StreamFeatureView = fs.get_feature_view(name=..., accept_type=StreamFeatureView)
...

fvs: list[StreamFeatureView] = fs.list_feature_views(...,  accept_type=StreamFeatureView)
for fv in fvs:
    ...

[tokoko]

It we really have this need, can't we apply an optional filter to return only instances of the requested type with no need to further check?

Let me look into this. This is actually probably a better idea since we'll definitely need something like this for list_feature_views method anyway, so why not here as well? I was just trying to keep the interface simple, because of the chain of changes this causes in registry server and so on.

P.S. I'm afraid linter issues won't go away even in this case. type annotation will have to be BaseFeatureView and some asserts here and there will be necessary.

[dmartinol]

P.S. I'm afraid linter issues won't go away even in this case. type annotation will have to be BaseFeatureView and some asserts here and there will be necessary.

Can't we surround it by cast? (asserts of accept_type can be hidden in the methods for all the clients):

fv :  StreamFeatureView = cast(StreamFeatureView, fs.get_feature_view(name=..., accept_type=StreamFeatureView))