People here have given you some nice practical suggestions; I just wanted to add a couple of higher-level comments.
I know I can ask my colleagues but at the same time i do not want to be constantly bothering them since problem solving is part of my job
A lot of us developers are the sort of people who take pride in our problem-solving skills, and so it almost feels unnatural for us to ask for help. You have to train yourself out of that mindset - sometimes, asking for help is in everyone's best interest (and you and your teammates can figure out how to go about help/training in a way that's not disruptive). Over time, you'll pick up on things, and you'll need less and less help. Also, the activity of trying to sort out (what appears to you as) the impenetrable mess of concepts expressed in legacy code is not the kind of problem solving that's at the center of your job description. It's grunt work. You want to get to solving the actual problems that the software was made for; some grunt work will be required to do that, but a little help from the more experienced members of your team can get you there faster. So it's a matter of finding a balance. A bit of struggling to figure things out on your own will lead to developing a deeper understanding of things, but don't go overboard.
My work environment is agile and I am expected to deliver quickly, but as a fairly new member of the company and a huge code base that was built before i joined, it is difficult for me to meet “agile” timing.
It's difficult to say what the exact source of the problem is without being there; every organization is different. In any case, because of the fact that you are a new member of the team, and that the codebase is the way that it is, it's a given that you'll be needing some help or training. Your organization should know this. The thing is, you are trying to solve the issue, but you are trying to figure it out while working with limited information and with untested assumptions (i.e., you don't know how your organization may (or may not) be able to help you with your issue, you assume your teammates will feel you are bothering them, etc.). You should ask around first; talk to people about these things. Then you'll know what the options are, who to else to talk to, and so on. Then you'll be in a better position to decide how to act.
How is one supposed to deal with such a huge code base where nearly every single line/function leads to another abstraction and within those are even more abstractions
What I'm about to say is more of a general remark, and not really intended to help you solve your current problem (except that it may offer a new perspective). When people complain about abstractions, it either means that they are unfamiliar with the concepts, or that the abstractions themselves are wrong. If it's the first one, great: that is comparatively easy to fix - these concepts and ways of thinking can be taught. The second case is not so easy. You see, good abstractions may introduce structural complexity, and a learning curve, but once you understand the concepts they represent, and the problem domain, they don't make things harder to understand or work with, they make them easier. They should be designed is such a way that, under most circumstances, you shouldn't have to dig 5 levels deep to understand how to write some bit of client code. In fact, there shouldn't even be 5 levels (from your point of view). They shouldn't be more complicated then they need to be. What sometimes happens is that people follow "best practices" without really understanding the reasoning behind them, and you end up with a lot of superfluous abstractions. Instead, abstractions should be designed very deliberately, as tools that make life easier for the developers. Maybe you are struggling with superfluous abstractions here. On the other hand, maybe the original developers had good reasons for introducing them. If it's the former, you can't do much about it, given your current position and the fact that it's a legacy codebase.