1) Should I stick to HTTP multi-part file upload no matter what in mobiles or is it fine to use FTP
Because of the design FTP is a very bad choice in any networks which use private IPv4 addresses - which due to the shortage of IPv4 addresses is the case with probably most mobile networks. While it might work within one network it will not work within another and if you try to combine FTP with SSL to secure the transport it gets even worse.
HTTP and HTTPS instead work usually without problems. With the use of Range requests you also have the ability to download parts of files, which is important when resuming broken downloads or loading only the necessary parts of a document (like parts of an big PDF file). FTP has limited resume capability but not as useful as the HTTP Range request.
As for resuming uploads FTP has the REST (restart) command. But you need to first find out how much data were received at the server so that you know where to restart. HTTP has no builtin resume for uploads. You could use the Content-Range
header within POST or PUT requests but your server need to understand how to deal with this header. Or you could spread the upload over multiple requests which again needs special server side code to rebuild the original file at the server.
The overhead for both protocols is about the same and could be ignored for anything but very small files.
2) My Server is FTP storage repository, can I still use HTTP to upload without issue
If your server has no HTTP interface then you cannot use HTTP. But just the description of "FTP storage repository" does not give enough information about the ways it can be accessed.
3) Does FTP use multipart upload just like HTTP or how is network issues handled when there is frequent breaks
If its broken you need to find out where to restart with the upload (check remote length) and then use REST command.