@jonay__reyes   I think by default you will see the result you are expecting,  however, the expected limit of 5 concurrent connections may be a challenge.     Let's address your questions first:

1. Does this translate to simply using 1 InvokeHTTP processor configured to 5 "Concurrent Tasks" and that's it?  -  1 proc w/ 5 concurrent tasks, will provide what is in effect 5 instance copies and they can run more than 5 requests each if there are ample flowfiles queued up.  So, NO.  For your use case, i would recommend that you set it to 1, and control the # of flowfiles upstream.
2. Will the processor wait for the remote endpoint's request before sending the next one?  YES if concurrent task set to 1.  NO, if set higher (2+) they will execute in parallel
3. How does the "Run Schedule" works together with the previous settings? (if I had, e.g.: 1 sec). Run Schedule sets how long a process will operate before a new instance is necessary.  If the request/response times are low, this setting will allow you to push more data through each instance without creating separate processes for each.  If the request/response time is high, you can use this to help with long execution.  Experiment carefully here.
4. I've been proposed with splitting the incoming queue and put 5 InvokeHTTP processors in parallel, each one attending 1/5 of the incoming flowfiles (I'd do the pre-partitioning before with some RouteOnAttribute trick), but I think it's exactly the same outcome as the 1. above. Is it?   Correct, there is no reason to do this,  avoid duplicating processors

For concurrent tasks and run schedule adjustments, you should always experiment in small increments, changing one setting at a time, evaluating, and repeating until you find the right balance.   I suspect that you will not need 5 long executing request/responses in parallel, and that even with default settings,  your queued flowfiles will execute fast enough to appear "simultaneous".