Hi OP, I had the same problem you're having, still do to an extent. I was the only dev at my first job and had no one in the real world to turn to. I learned several things from a friend who was already in the industry for years before I got into it when I was searching for my second job, and I'd like to share them because your question will get slathered in the typical HN well-meaning yet empty responses:
> How would I unit test an http handler func that is the entry point for a RESTful API? I need to do authentication, database access, and return some JSON data. How do I keep the test as one "unit" when I need to do all of these things?
At this point, you're ready to ask "real" questions on places like StackOverflow, Reddit boards, and chat rooms (Discord, Slack, Gitter, IRC, etc). You have enough understanding of the technical jargon to postulate questions to the community at large. I asked a question on SO about how unit testing in Android works because I was getting a NullReferenceException - you know, the type of problem that gets badgered with the standard and huge SO answer about NullReferenceExceptions[1] - and I got a really nice answer that taught me a fair bit about the Android ecosystem. Put enough thought into your question, include code and links to stuff you've done, and most of these resources will bear fruit for you.
Another benefit of joining these communities is if you get into the chat room ones and become a known face, people will genuinely want to help you. I learned about the history of delegates and how to write extension methods because I was chatting about going through "C# 6.0 and the .NET 4.6 Framework" and had some questions about delegates, and one of the members set aside some time over a few days to give me a small challenge for writing an extension method, explaining delegates along the way.
> Again, this is just a singular example, but the theme is pretty consistent across any higher level programming challenge I come across.
This is the time where you can also start reading books like Code Complete and get something out of reading it. Pick up some of the usual suspects like Clean Code, Code Complete, Working Effectively With Legacy Code, etc. and get crackin'. You can treat Code Complete sort of like a manual that you peruse the chapter list and see if it has a relevant chapter to your problems and give it a read, or go through it cover to cover.
> "skills chasm"
I know I just told you to spend money on books, but a resource that was REALLY good for building skills was Pluralsight. For me, since I was working in C#, I perused the C# Path and learned about equality, LINQ, etc. Some of the courses get really specific and deep into it; for even more depth, you might have to turn to books. Actually, there's an intermediate course on Pluralsight called "Creating Well-tested Applications in Go" which might benefit you immediately but YMMV.
It's the go-to that just works for building skills so everyone spits it out immediately, but yeah, as much as I dislike people who just go "projects help you grow!" and drop the mic, projects are gonna help you out a lot. If you can't do big things because of work or time constraints, do small things. An example I can provide was learning about reading/querying .sdf files, which meant I had to do some digging into deprecated libraries and tech. I did a little playing around with some sdf files in LINQpad by connecting to it and simply reading some values. Small things build up.
[1] https://stackoverflow.com/a/4660186