`truncation='do_not_truncate'` is not equivalent to `truncation=False`
### System Info

- `transformers` version: 4.21.1
- Platform: macOS-10.16-x86_64-i386-64bit
- Python version: 3.9.7
- Huggingface_hub version: 0.8.1
- PyTorch version (GPU?): 1.9.1 (False)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed
- Using GPU in script?: no
- Using distributed or parallel set-up in script?: no

### Who can help?

@SaulLu @patrickvonplaten 

### Information

- [ ] The official example scripts
- [X] My own modified scripts

### Tasks

- [X] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [X] My own task or dataset (give details below)

### Reproduction

```python
from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("facebook/bart-base")
sent = 'The quick brown fox jumps over the lazy dog'

len(tokenizer.encode(sent, max_length=5, truncation='do_not_truncate'))
```
prints: `11`

BUT:
```python
len(tokenizer.encode(sent, max_length=5, truncation=False))
```
prints: `5`



### Expected behavior

Hi,
I would expect that `truncation='do_not_truncate'` would be always equivalent to `truncation=False`.
This manual: https://huggingface.co/docs/transformers/pad_truncation and this doc https://huggingface.co/docs/transformers/main_classes/tokenizer
say that:
>`False` or `'do_not_truncate'`: no truncation is applied. This is the default behavior.

Which means that they are supposed to be equivalent (regardless of what they do, they should behave the same).

However, when using `truncation=False` and providing any value for `max_length`, it defaults to `'longest_first'` truncation strategy.
Whether this default behavior is natural or not, isn't `False` supposed to be identical to `'do_not_truncate'`?

This leads to a situation when the user explicitly specifies `truncation=False` but the text **is tokenized**.

I suggest that `truncation=False` should always mean "no truncation", no matter what, regardless of `max_length` was supplied or not.
I think that this is the expected behavior by any user: explicitly specifying `truncation=False` should mean no truncation, regardless of other parameters.

Thanks,
Uri
It looks like the PR that set the current truncation/passing arguments has some behavior for backward compatibility that is triggered when `truncation` is unset. However, instead of having `truncation=None` as default (to make sure to detect when it's unset), it uses `truncation=False` as default. So in this instance, even if you passed along `truncation=False`, it activates those tests for backward compatibility.

It is way safer to use `truncation="do_not_truncate"` to avoid this. I'll investigate if we can fix this without breaking anything (by changing to `truncation=None` as default for unset beahvior). <|||||>Thanks!

Yeah I know that it's safer to use `truncation="do_not_truncate"`,
but passing booleans is kind of safer than strings in general (and it's shorter), 
so (since the docs allow it) I passed `truncation=False` and I found it very unpredictable that truncation was applied, even when I explicitly passed it.<|||||>Awesome, thanks!