Unless you have the database clustering in place, LXD doesn't know whether the target host is talking to the same ceph cluster, nor is there a way to make a quick clone across two rbd storage pools. So while we do use optimized ceph tooling for migration today, it doesn't save you nearly as much space as it could if the pool was truly shared.
With the LXD clustering in place, your "lxc list" will show you containers running on all your hosts. The containers will still be tied to a particular host but can be moved within the cluster as you want. When those containers are entirely based on ceph for their storage, such a container move would be instant as no data would actually need to be moved, it'd effectively just be a DB field update to point to the new host.
As for using btrfs on top of an rbd volume, it really depends on whether you need any of the btrfs features inside the container. If you don't plan on using btrfs subvolumes inside the container, then btrfs doesn't really get you anything in this case and going with ext4 is probably a safer, more reliable choice.