You will not win this battle, and switching ISPs seems like a pretty knee-jerk reaction, especially if your ISP is already working well for you (for general Internet service), compounded with the fact that most US cities are still lucky to have more than 1 ISP choice. Don't change ISPs, and don't sign up for their exorbitant "business class" service either.
Even if your ISP wasn't
filtering inbound TCP SYN to customer WAN IPs on their border routers -- which from your description it sounds like they are, and which is perfectly within their right -- if you ran a server, you'd still be violating their ToS and thus potentially subjecting yourself to service termination. If they have a FAQ/ToS entry about it, you should probably adhere to it else accept the risk. Hint: it is very, very common for ISPs to port scan customers.
So here's two pieces of advice, take them or leave them:
1. Don't run a server on your home connection. Buy yourself a cheap VPS (see: $7/month, sometimes less) and stop worrying about it. You now have something that's totally accessible via the Internet, and you can do nearly whatever you want however you want, all the way down to maintaining firewall rules yourself. Get something that has actual serial or VGA console access (i.e. not only SSH).
2. If your goal is to be able to access home resources from somewhere (i.e. you're using a laptop and wish you could access your home web server to view some web pages, or remote desktop in to a machine on your LAN, whatever), and the service you want to access is TCP-based, then use the fact that the ISP permits inbound TCP port 22 to your advantage: forward 22 to your "LAMP" server running OpenSSH. Now use SSH port forwarding/tunnelling, in your SSH client (on your phone, on your laptop, whatever) to forward, say, 127.0.0.1:1234 to 192.168.1.99:80 (where 192.168.1.99 is your "LAMP" server), then access the URL http://127.0.0.1:1234
in your browser on the machine running SSH. The advantages to this are several, but the two big ones are: i) the only way "in" to your network is through SSH thus you don't have to worry about Internet users finding Apache exploits etc. and destroying your box, ii) all traffic across the SSH tunnel is encrypted (read: cannot be sniffed or identified), e.g. your ISP would only see "a bunch of SSH traffic" and have no idea if you were using it to tunnel HTTP traffic or whatever else you might find useful, iii) a sub-set of (i): you can lock down what IPs have access to port 22 via firewall rules on the "LAMP" box, that way only places/networks you'd be accessing things from would even know that TCP port 22 was listening at all (read: ISP port scanning you would turn up nothing). However, this overall method only works with TCP; SSH does not support UDP port forwarding/tunnelling, so if you need UDP access, you're SOL. Be aware that even with this method, you're still violating their ToS on some level (but I will say that many ISPs with this ToS clause actually let SSH slide most of the time).
P.S. -- Apache will listen on TCP port 22 just fine. There is nothing "magic" about 22 vs. 80 vs. 443 vs. 1234 vs. 8080 vs. 6667 vs. 28549. You have some other daemon listening on that port, or a router-related nuance relating to that port that you haven't figured out, which is the root cause. However, I assure you, you do not want Apache listening on port 22 on the public Internet. I'm not going to explain why either, to force you to go digging to find out what sorts of crap flies across/at port 22 in this day and age. Likewise I suggest not leaving port 22 w/ OpenSSH open to the Internet either, instead lock it down to specific IPs or networks you wish to come in from. Go figured out/read about why, you'll thank me later.