There is no way a transaction which is sent but not confirmed yet could be cancelled. If this was the case, then people would exploit this for double spending. If you don't want the transaction to get delayed, its best to use the default fee and do not change the fee to too low that it takes many days to confirm.
You can. If you send a miner another transaction spending the same inputs, the miner can include the transaction into a block that they will mine. The transaction which gets confirmed depends on which miner includes which transactions first. That is how some pushtx website works, that is if they allow you to submit an alternative transaction.
The scenario is with a transaction without opt-in RBF. Without that flag, nodes will not relay your replacement transaction with a higher fee and thus suffers from poor propagation. If you don't have that set, you have two solutions:
1. Child Pay for Parent. By spending one of the outputs with a higher than proportionate fee, miners could include both your "parent" transaction as well as the "child" transactions and thus resulting in you getting a confirmation for both. This only works if you control any of the outputs for that transaction.
2. If the transaction doesn't get mined within a period of time, nodes could drop your transaction and you can create a new transaction with the new transaction having a better propagation. This is dependent on if your wallet provider rebroadcasts your transaction or not.