Does BLE device generates new LTK, CSRK, and IRK every time it bonds with new device?

The IRK is always constant (the same IRK is shared in every pairing attempt) and is used to create random resolvable addresses. Devices that receive an IRK from a remote device can then figure out if a random resolvable address belongs to a particular IRK.

All other keys are unique for every bond.

The CSRK must in particular be unique for every bond since there is a counter associated with it, incremented on every packet write to avoid replay attacks. This would not work security wise if two bonds have the same CSRK, since an attacker could then replay packets from bond 1 when impersonating bond 2 (assuming the packet counter is less for bond 2).

The LTK, EDIV and RAND are used to derive a session key for encryption the next time a connection between the same pair of devices connect.

Thus the answer to Q1 is that the keys are reused for every new connection attempt between the same pair of devices, as long as the bond exists.

If you in particular copy the IRK from one central to another, then yes a connection between P1 and C2 can be made and all the other keys can be used during this connection, if C2 uses a random resolvable address. This is because P1 believes it talks to C1 due to the random resolvable address. After all, on the Link Layer it's impossible to tell C2 and C1 apart if random resolvable addresses are used with the same IRK.

If random resolvable addresses are not used, then it's usually not possible to copy a set of keys between devices. This is because the keys are associated with the Bluetooth device address (public or static random). If a central using a different address connects to a peripheral, the peripheral will look up bonding keys in its database to find out there are no LTK, EDIV, RAND, CSRK stored for this address. In some implementations though for encryption setup, the peripheral will look up the LTK based on EDIV and RAND instead of the address. In this case copying of keys will work, at least to establish encryption. The CSRK is always looked up from the address though. Note that for LE Secure Connections, EDIV and RAND are always 0 so in this case the LTK is always looked up from the address.

Note that the use of CSRK is not widespread at all. I have not seen any implementation use it in a real product. Since only the "Write Without Response" command can be used with CSRK and the fact that a counter must be stored persistently, normal authenticated encryption that covers every kind of packet is usually a better idea, since the few encryption setup packets can usually be tolerated.

The connection is terminated between P1 and C1. Later, when both P1 and C1 connect again, will the two devices use the same LTK, IRK, and CSRK keys that they used in Case-1?

Yes, they will use the same keys. You only disconnected, the bond is still there. You need to remove the bond to delete the keys.

Let's say a new central (C2) comes into the picture. P1 is no longer connected to C1. P1 now wants to connect (with bonding) with C2. Will the P1 use the same LTK, EDIV, RAND, IRK, and CSRK that it had used(generated) earlier to connect with C1 in Case-1?

No, P1 and C2 will come up with new keys for this connection during the pairing process.

Do the BLE devices use different keys (LTK, EDIV, RAND, IRK, and CSRK) with every new device they connect with?

Yes, they do. The keys depend on the devices and are therefore different for each device.

If I take the keys (LTK, EDIV, RAND, IRK, and CSRK) stored in the C1 and store them in C2, can P1 connect to C2 using the same keys? Is it possible to make this work or it is incorrect logically and from the security point of view?

Theoretically yes, but it might be impossible to extract the keys from a system due to security reasons. It is a security feature that every connection uses its own keys in case one connection gets compromised.

Without bonding, the devices need to pair for each new connection and will use new keys. They get stored during bonding to prevent the devices from needing to pair again next time.

The pairing process is described further in chapter 2.3 of the BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part H (page 1636).