This card is a follow up on #479, and specifically this comment

The goal is to add tests and/or the functionality referenced in the above comment.

• Feature references cannot contain a project when it is in string form. This is to prevent multiple projects from being selected in a single feature request (for retrieval).
• Feature References can contain projects to prevent breaking changes to existing clients. An additional field feature_set_name is used to reference a feature when a single feature name is ambiguous.
• Projects can only be defined once per incoming request. There should be a single key on each Feast client to set the project, since projects aren't defined in the feature reference any more.
• SDKs to add a field project to allow users to override projects for all given feature references. Moving forward this would be the preferred way to set projects, not in feature references, although that is still accepted for backwards compatibility.
• If a project isn't defined then the default project is used. The default project is just called, "default".
• The default project is set on the server side, not the client side. Clients should not have to provide a project.
• Feature names may be duplicated across feature sets in the same project. Currently they have to be unique in a project.
• All tests need to be updated according to the above functionality.
  • Specifically we should make sure that we do not set or create a project by default in any test, unless we are testing project functionality specifically. Projects should be invisible if the user is just using the default project.