Hi SamehCode01.
First, I want to provide some encouragement. I am an “old-timer”, as one might say, and although I “know” JavaScript, I wanted to get my skillset modernized and possibly drop some cruft from my brain. (The VAR replacements and reasoning have already improved me). However, I also was totally stumped when I encountered this challenge and had to step back and try several things to get it solved. I share this to demonstrate that even professional programmers hit walls. You are not alone, and it is NOT uncommon at all to encounter challenging tasks. It is actually quite normal.
Secondly, although you may be unsure, @Teller and @JeremyLT are doing you a GREAT service in pressing and pushing you to do something that, unfortunately, only good developers do today: problem-solve instead of “find the answer”. Problem-solving requires writing the problem in front of your face and making your brain solve each tiny piece. I cannot tell you how many times I have seen developers get stuck because they could not “find the answer” on the Internet, only to get the great AHA moment when a few simple questions are put to them. It might appear to be a subtle comparison between solving the problem and finding the solution to the problem, but it is significant factor between junior and lead developers.
Lastly, as I had the same issue as you and seeing that you have wrestled with this for a few weeks now, I wanted to share my notes (aka plan) that I had drafted after I made the bad assumption that this challenge was “supposed to be” short like the one-liner from the previous challenge. Never assume.
Please trust me when I say this mental exercise will not only make you a better programmer but a faster problem-solver. Try to completely ignore whatever language you are writing in to solve the problem, and just focus on the basic step-by-step tasks (i.e., algorithm) you need to execute. The plan DOES NOT care about the programming language.
Sorry, one last thing. There is no wrong or right answer. There is working code and non-working code. Code can be refactored and improved, but ultimately working code of 20 lines and working code of 1 line have the same thing in common: they work. Don’t get hung up in perfection. Refactoring comes later, and I bet many here would agree they have created solutions faster by writing their long straight-from-the-plan version first and then translating to code and then refactoring, over perfect short code that took forever to conceptualize in their mind and actually write.
Anyway, enough back-slapping. Time to hit the field. 
/*
My function's algorithm/steps/plan (pseudocode)
- Create an empty array called "matches" to store objects that have
the same properties (and property values) as the source object.
(This will satisfy requirement 2).
- Iterate through each object of the objects array, and
- Test whether all the source object properties exist in the
object under test (i.e., the object of this iteration).
- If a test fails, continue (skip) to the next object
- NEW: Test whether the source object property value matches
the value of the obj property under test.
(See DELETED below for explanation of "NEW")
- NEW: If the test fails, continue (skip) to the next object
- If no test failed, then add this object to the "matches" array
(because the object has at least the same properties as the
source object)
- DELETED: Next, I need to iterate through the "matches" array
(objects that at least have the same properties as the source
object) to test whether they have the same property VALUES.
- DELETED: Test whether the source object property values match
the property values of the object under test (which means I
would have to start another iteration through what I already
did so ... drop this idea, and instead check for the value in
the iteration above when I get a successful property match.)
- Return the matches array (it will still satisfy requirement 3
if I was not successful in finding any matches).
*/