Honestly while this particular Team Lead does sound somewhat obnoxious I think the root cause of the contention is down to a mis-match of expectations. He was expecting a dev who was more self-sufficient and you were expecting to be more spoon-fed. I'm not saying either stance is wrong - more that they clearly aren't a good fit for the two of you and while I'd hope that some of the less pleasant attitude the Lead showed wouldn't be common many of the specific hurdles you encountered will be:
"I'll have to look into it, so you might as well do it."
On larger, more complex code bases it's absolutely to be expected that the Team Lead doesn't know all the ins and outs "Encyclopedia" is generally not in the job description. A good Team Lead however should generally be able to point you in the direction of someone else on the team who does know the answer (or at least knows a decent amount about the area you are looking at). Sometimes however there simply isn't anyone (due to staff turnover, sickness, holidays etc) in those cases "you might as well do it" is about the only answer you can expect and you have to be prepared that you will not infrequently be expected to be able to figure that stuff out on your own as a last resort.
Its frustrating as the code base is not in the least bit documented. I had approached the guy multiple times only to be swatted away.
Best will in the world the majority of code bases I've worked with aren't documented. Even when there is every desire to get it done by the dev team there often isn't time allocated for it by the business. An in reality I'd expect a competent, experienced developer to be able to (mostly) figure it out from the code unless it's especially awful or obfuscated (been there, done that!). And in the (rather likely) eventually that it isn't documented then there's no real point in approaching the team lead "multiple times" over it - they certainly aren't going to drop everything and generate a load of documentation simply because there's a new team member. You just have to figure it out as you go, and it's probably a good idea to document as traverse the code and learn - even if it's just a comment or some notes for yourself.
More than once during my career I've been brought in to work on code where there was literally no-one in the business who knew anything about the code (usually because of an acrimonious split with a prior dev/dev team, although there was one memorable instance where it was because the poor guy had died suddenly!)
Now that I learned the code (to some extent), I am quite angry as now I see how I used to slog over for doing something simple (and readily coded). I wasted a lot of time on this.
I may be misinterpreting your meaning here - but isn't this totally normal? The more you get to know a code base the easier and faster it gets to work on. But the only way to get to that point is generally to slog around a bit and learn the code.
The management is not concerned at all.
Given the amount of times I've seen management be of the opinion that their twenty-year old code base with millions of lines of code doesn't have a learning curve I would think having them be "not concerned at all" that you had to spend some extra time on even relatively simple tasks while you got up to speed on their code is a Good Thing(TM)
Multiple instances, I code something; only for it to come up during code review. I get a: "You could have done this instead" after him telling me off for the same problem.
Without knowing more specifics this sounds like the code reviews were functioning normally to me.
I recently (after giving my resignation) started documenting the code as I didn't want the next guy to go through the same thing (when I am done with my work). Apparently (as per the same guy) I am wasting company time and should instead go home if I am done; taking a half day.
This sounds like a pretty poor attitude from him to me (as I mentioned above), I'd probably counter by asking if you'd be getting paid for the half day at home (if the answer is yes then feel free to leave a Bhoot-shaped hole in the wall on your way out!) but if not then ask him if there is anything he wants you to work on as a priority over the documentation.