I guess all of the big telcos have some homegrown ossified hacky "solution" that also serve as a minimal kind of "firewall" for SS7. (Basically I imagine that there's a lot of hardcoded rules for phone numbers, country codes and operators. Sure, they probably are an opposite of a problem for national intelligence services, after all it's easier to go by unnoticed in the noise, but they at least help with a total BGP-like hijack of a whole country code by an operator.)
There are product-based SS7 protocol firewalls available that try to detect the "patterns" of signalling used to do "bad things", and block and report them.
Part of the problem with SS7 is that it's complex, and you can't easily restrict who says what - if you port your number from Operator A to Operator B, your number prefix still sits in A's range, and calls are signalled to Operator A. They can then tell you to try Operator B. B may then need to tell you the user is roaming and how to reach them. But yes, current firewlls leave a lot to be desired!
There's a number of good talks from CCC about SS7 - one is https://media.ccc.de/v/31c3_-_6249_-_en_-_saal_1_-_201412271...
Not in all networks as far as I'm aware. UK is an annoying example of not having a central database of ported numbers (with ACQ), where a redirect is setup in the old network. I once ported my number in the UK and had huge issues receiving international calls or 2FA codes, it took me ages to work out and only got it sorted by leaving the number entirely and getting a new one.
Otherwise, like here in Germany, it's done with a proper database and the call never passes through the old network.
As you say, this is the legacy system, but it's still a huge problem for them!
Hopefully with the (slow) move to 4G and IMS calling, we can turn the page on SS7 attacks soon.
Yes, because it's a centralized meta-control plane of/for BGP. But no, because after all IP address space is already centrally managed anyway: IANA -> RIRs (-> LIRs), but not really, because each AS decides what to do with RPKI data.
So it's much better than parsing RIPE plain text query reults, and it's the correct fix for hijackings.
"Real-world censorship resistance" is not in the threat model for the current Internet at the RPKI/BGP/RIR level, but it's very much in scope for high-level protocols like DNS, TLS, HTTP (as privacy concerns).
See https://tools.ietf.org/html/rfc4593 and https://tools.ietf.org/html/rfc7132 Regular ("in-band") DoS or tampering attacks on RPKI databases and CAs (certificate authorities) are of course taken into consideration - even by nation states. Though these particular RFCs don't offer a particularly systematic and ironclad solution. (The problem is punted to users: "just use (stale data and) caches, decide for yourself what to do if the central DB is unavailable".) Likely there's some other RFCs that offer better answers with - hopefully - more operational detail.
Building a truly global efficient/high-bandwidth/low-cost "infinitely" censorship resistant Internet is (very) hard. Currently traffic passes through various networks, those "autonomous systems" have the capability to direct (and filter, eg. null route) traffic. Source routing in theory might help with working-around bad AS-es, but even detecting such AS-es seems hard theoretically. And on top of all that there's the economic aspect. (How would the network/users/operators incentivize each other to work around bad ASes?)
Hence IPsec and site to site/road warrior VPN - the underlying connectivity is regarded as untrusted by any sane user.
In telecoms, anyone on the SS7 network can make a request to find a given number, or say the number is available and can be reached by routing via their network.
That's only a small piece of the puzzle in network security generally, but is sure better than how SS7 works right now.