Ok, so, CSRs are not really related to a CA. CA's can have requirements about aspects of them, but they're mostly CA-agnostic in general. I don't know what Symantec may add to their CSRs, but I wouldn't anticipate it upsetting Let's Encrypt.
CSRs in general are just a specially formatted bundle of information: Domain name, SANs, some demographic info that's often ignored, and very importantly, your public key corresponding to a private key you hold on to. A simplified but still accurate picture of what happens next is that once the CA gets this CSR, they process it and sign your public key and adjoining information with their private key. This is the certificate sent back to you.
So, you have a few options. If your CDN is unwilling or unable to let you specify a new private key, you have to use their CSR. However, if you can send them the private key of a CSR you generate yourself, no problem. Either way, you could just do something like use DNS validation and get a certificate from somewhere like https://zerossl.com/. You can let that generate a new keypair in-browser for you and get your cert, or give it your CSR and see if Let's Encrypt can turn that into a certificate.
As for replacing the certs, not necessarily. You can issue multiple certificates for identical domains (up to rate limits) and it will not invalidate your previous ones. Of course, if you do this with certbot's automated methods, then it will replace them itself. You can prevent this with --cert-only, I believe (check docs for Certbot). However, it doesn't really matter if you replace them, the new one will still be valid and can be used in multiple places if you want.
Now, bear in mind there's a 90-day validity period on these, so you'll probably want to work with Akamai on getting this automated somehow.