A huge part of that is how to structure an open source project so that it can't be taken from the community. Basically a combo of GPL and taking community contributions without having them assign copyright to you is the most full proof way to keep something open source.
To answer your question, if they own everything they can relicense it any way they see fit. Only by having your code mixed with others' that you don't own can you practically protect it from forced relicensing.
Sorry, but your advice is refuted by research. Both GNU and Apache ask developers to sign contributor licensing agreements. For Apache, see “ASF Contributor Agreements”, https://www.apache.org/licenses/contributor-agreements.html. For GNU, see “Copyright & Compliance” at https://www.fsf.org/licensing/.
The Wikipedia article about Contributor License Agreements cites this article by OSS Watch, http://oss-watch.ac.uk/resources/cla. This is the first time I’ve heard of OSS Watch, but they might be a helpful source of legal advice based on their About page, http://oss-watch.ac.uk/about/
There are also arguments against them in many cases, including that they create friction for new contributors. "Oh, I have to sign this agreement which means talking to my company's legal staff? I think I'll just pass."
The parent is also probably right that GPL with no CLA makes it much harder to change a project's license. This actually came up when GPL v3 was released. As it turned out, Linux apparently didn't want to change Linux from a v2 to a v3 license. But there were also legal questions about whether he could do so by himself even had he wanted to. (Though Eben Moglen argued at the time that he maybe possibly could have for various arcane reasons.)
ADDED: I recorded a podcast on this and related issues recently: https://podcasts.apple.com/us/podcast/open-governance-chris-...
In the podcast episode, the guest does mention people are moving away from CLAs. He goes on to say projects are adopting a “Developer Certificate of Origin” model. I found an article that helped me start to understand differences in these models: “CLA vs. DCO: What's the difference?”, https://opensource.com/article/18/3/cla-vs-dco-whats-differe....
I have issues with the GNU assignment. It means that we're reliant on future owners of the GNU project to not ever relicense the codebase. A single owner is a single point of failure.
The FSF is arguably something a bit unique. But most of the point of a CLA is to give a company/organization ultimate control over a code base so that it can dual license, etc.
https://legacy.gitbook.com/book/hintjens/social-architecture...
Your employer isn’t seeking a copy of your Apache 2.0 code, which they already have, they’re seeking transfer of copyright ownership.
It really does sound like you’d learn a lot from talking with a lawyer, maybe one recommended by an open source foundation. Lots of lawyers have a first meeting is free policy, so schedule meetings with a few lawyers. Pick the one you like best, or pick none.