What happens if multiple users send requests to the server concurrently?
It depends on what the requests do. If they're just reads, nothing happens. If they're, say, incrementing counters, or changing variables, then Alice might send "SET x=15" while Bob sends "SET x=42" and Alice might think x is set to 15 while it is actually set to 42. In complex scenarios where data are then reused for calculations and error might snowball fast, this is very bad and you avoid it with several so-called locking strategies.
Is that important to prevent that? (Make the users fill in all the inputs before sending the requests)
That's surely beneficial: ensure that the least possible data in the least possible number of calls is subjected to slow network round-trips. So, do also all the checks you can client-side. But keep the checks server side too, as the clients must never be trusted.
How can i know if the server can handle those requests based on the concurrent users?
You test. You use tools like Apache's ab or httperf or Casper-Load or whatever.
What type of testing is the reduction of those http requests?
I guess you might call it efficiency, but it's a metric and not a test, and however you must also remember that you're seeking a trade-off; you must balance development effort, maintainability, expandability, performance and data integrity. There most definitely isn't a one-size-fits-all solution, you need to verify what your design requirements are.
Update based on comments
Actually, my project accepts inputs from the users and sends them to PHP for validation
Then perhaps most of the issues disappear. If the "validation" is completely defined by the user's request, and all users have a single login each, it will never happen that one user's request can interfere logically with another's.
There might be resource contention (e.g. one validation takes 2 seconds of 100% CPU, then you don't want more than one request every 2 seconds, or the server would lag behind). You can make this a UX issue by creating a "ticket service" by which you quickly "reserve" a ticket and the server books your validation for, say, 60 seconds from now. The client code is then forced to wait (displaying a count-down) and submit the request only one minute later.
Otherwise, you need no special "defenses" - PHP threads will answer each to their own requestor, the HTTP protocol takes care of that.
How could i prevent PHP from sending a response if a validation is wrong?
You must not. You always send a response, you just say 'OK' or 'Wrong'. If you don't send the response, the client is left hanging, and the user dissatisfied. If you can't perform the validation you send a HTTP error code stating why it is so (40X for user error, 50X for server errors).