show extended index equivalent for MySQL 5.7
But it’s safe to assume PK is indeed present ?


Yes.  (The following applies only to InnoDB; other engines probably differ.)


A copy of the PK column(s) is tacked on the end of regular indexes.
FULLTEXT and SPATIAL work differently, so this discussion may not apply.
There has been some chatter about whether the FK columns are redundantly added, or only if not present in the declared index.
The benefit of the PK columns being tacked onto an index is for "covering".  This provides a (perhaps) 2x speedup.  Example:  Given PRIMARY KEY(id), if you also have INDEX(x), then SELECT id FROM t WHERE x=1 (without any other columns mentioned), then the query can be performed in the BTree for the index since it is effectively (x,id).
UNIQUE and non-UNIQUE work the same except for the uniqueness constraint.  This constraint applies only to the columns specified.  That is, given PRIMARY KEY(id), if you also have UNIQUE(uuid), then uuid is checked for uniqueness, even though the BTree containing that index has (uuid, id).
The PRIMARY KEY is a UNIQUE index, but it is different because it is clustered with the data.  That is it is in the same BTree and that BTree is ordered according to the PK.
Hence a "point query" using the PK, is a simple drill-down of the PK+data's BTree.
But a "point query" using a secondary index needs to first drill down the index's BTree to find the PK, then drill down the PK to find the row.  (Exception:  "Covering index", see above, avoids this second drill-down.)