BUG: iloc fails with non lex-sorted MultiIndex #13797
- [x] closes #13797
- [x] tests added / passed pandas/tests/test_multilevel.py
- [x] passes `git diff upstream/master | flake8 --diff`
- [ ] whatsnew entry

corrected how iloc handles tuple-keys for multiindex

## [Current coverage](https://codecov.io/gh/pydata/pandas/pull/14038?src=pr) is 85.23% (diff: 100%)

> Merging [#14038](https://codecov.io/gh/pydata/pandas/pull/14038?src=pr) into [master](https://codecov.io/gh/pydata/pandas/branch/master?src=pr) will decrease coverage by **<.01%**

``` diff
@@             master     #14038   diff @@
==========================================
  Files           140        140          
  Lines         50563      50563          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
- Hits          43101      43099     -2   
- Misses         7462       7464     +2   
  Partials          0          0          
```

> Powered by [Codecov](https://codecov.io?src=pr). Last update [6c73e76...1cf86a1](https://codecov.io/gh/pydata/pandas/compare/6c73e765a5f1191c954c7789791818d2685c3c2c...1cf86a184739191af54a28c6a2664b2166c49c78?src=pr)
 Yikes! This is a testament to how convoluted the indexing code currently is. If we did this right, it would not be possible for code using iloc to get anywhere near checks for multi-indexes. 
 > If we did this right, it would not be possible for code using iloc to get anywhere near checks for multi-indexes. 

But should it? For `iloc` it shouldn't matter if you have a multi-index or not how the indexer is interpreted
 > Yikes! This is a testament to how convoluted the indexing code currently is. If we did this right, it would not be possible for code using iloc to get anywhere near checks for multi-indexes.

This is not a helpful comment. This is just an implemention detail of the indexer. It could be a sub-class but its not, otherwise this would just be an overriden method.
 > This is not a helpful comment. This is just an implemention detail of the indexer. It could be a sub-class but its not, otherwise this would just be an overriden method.

This fix looks fragile to me. That said, it's probably the right choice for now. It fixes the problem at hand, but its not obvious that it's fully correct, because too many different code paths reuse the same logic in different ways.
 can you rebase / update?
 Yes. I can probably find a time tomorrow.
 @jreback 
Sorry for taking this long time. I added some comments, and modified the test code so that the test purpose became clear (i.e. iloc handles tuple as an integer locator instead of trying to interpret as multiindex representation.)
 thanks!
