Who mainly provides IP addresses to domains? As in, who commands, "www.google.com, 103.233.38.93 is yours; www.stackexchange.com I will assign 104.16.115.182 to you; etc."
Normally IP addresses are given out by providers to their customers. Small hosting customers will get IPv4 IPs allocated one at a time to their servers. Some organsiations will run their own neworks and have their own blocks of IP addresses either allocated by their provider or in the case of larger organisations direct from a RIR (google for example have their own IP space, I dunno about stackexchange). IPv6 IPs being so plentiful are usually allocated in blocks even when a customer only buys a single server.
IP addresses are allocated to networks by RIRs (ARIN, RIPE, APNIC etc). However the regular "free pool" of IPv4 addresses at most RIRs has now run out (there are some IP addresses held back by the RIRs for specific purpose allocations). So companies wanting more IPv4 adresses now have to buy them on the market and get the RIR to transfer them.
The customer then sets up their DNS records to point their domain name(s) to the IP address(es) that are allocated to their server(s).
Is there a possibility of IP address assignment duplication between two domains? If yes, is it bad? What happens if there is a duplication?
You can host multiple hostnames on the same IP address through a process known of as name based virtual hosting.
A complication in the past was that you could only have one ssl/tls certificate per IP address and using the same certificate for multiple independent sites was tricky. In principle one certificate can cover multiple hostnames but the certificate would need to be reissued each time a hostname (or wildcard group of hostnames) is added and if the hostnames belong to different domains convincing the CA that you have legitimate control of all of them may be difficult.
Recent versions of tls have an extension called server name indication which allow multiple certificates per IP. Unfortunately it has taken a long time for client support to become ubiquitous. Internet Explorer on Windows XP and the default browser on android 2.x being the main browsers that don't support it. Both are in decline but that decline has been much slower than people hoped. If you have to serve non-browser clients then the picture can be less rosy.
Also each IP address has to be assigned to a machine. So if you want to host sites with the same public IPv4 address on different machines you will need to use some sort of reverse proxy service (with the backend links to the servers going over IPv6 or private IPv4).
The limit of IPv4 Address is 4,294,967,296.
Actually the practical limit is much lower than that. Many large blocks were assigned to special purposes. Many companies who got their addresses early got assigned much larger blocks than they really needed due to classfull addressing and even with CIDR the power of two block sizes lead to many wasted addresses. The "Class E" addresses are effectively unusable because some vendors interpreted "reserved" as "refuse to have anything to do with these addresses".
As of 2015, there are about 863,105,652 websites and 3,185,996,155 internet users. It gives us at about a total of 4,049,101,807 possible IP Address assignments. If IPv6 is not implemented and the IPv4 limit is reached, what happens to IP address assignments if it runs out of IP addresses to be assigned?
As IPv4 addresses get in more and more limited supply the market price of an IPv4 address is likely to rise (it's currently about $10 per IP which is pretty cheap). As the price rises people will re-evaluate what applications can really justify a public IPv4 address and what applications will have to make-do without one.
There are mechanisms that can be used to provide some degree of connectivity to the IPv4 internet while reducing the consumption of public IPv4. On the client side a provider can either use conventional IPv4 NAT ("CGN") or they can use IPv6 based transition mechanisms like NAT64 or DS-Lite. Mobile providers have been doing this for years, fixed-line providers are just starting to trial it. I expect the lowest tier customers to be pushed behind ISP level NAT first with more expensive packages retaining a public IPV4 address.
NAT doesn't really work on the server side. You can forward ports but that doesn't really help when everyone wants ports 80 and 443. Instead the solution there is reverse proxies. These accept the TCP connections from clients and then look at what the client sends to decide where to forward the connection to. For plain http they can use the http host header (as used in name-based virtual hosting). For https if the client supports SNI then they can use the SNI information to forward the connection at a TCP level without decrypting the ssl/tls session. If SNI is not supported then the proxy must terminate the ssl/tls connection and look at the host header inside. If the certificate the server presents doesn't cover the domain the client is trying to access this will cause a certificate warning.
Hosting with provider operated reverse proxies is still a fairly new thing (I'm only aware of one provider doing it) but I expect it to get more common as the IPv4 crunch deepens.
