Custom HashMap Implementation in java
Here are my comments, in decreasing order of severity:

1) BUGS


Hash function: your hash function does not refer in any way to the bucket (changing) capacity.  The main problem with that is that the function may produce values that are outside of the index bounds of the bucket array (current function may even produce negative values) and then your add() method would throw an exception. but even if you protect from such cases, the function needs to refer to the current capacity in order to spread the values as evenly as possible across the buckets.  
Load factor: The code does not refer to the DEFAULT_LOAD_FACTOR: nor does it allow the user to override this value, and more importantly, it doesn't consider this when deciding if the bucket array  needs to be enlarged.  In fact, the whole logic of this decision seems to me to be wrong: when all entries in the bucket are full, you decide to enlarge the size. so theoretically, on the 11th add() call, you would enlarge the size.  This logic needs to be redesigned and it needs to be based on the total number of Entity instances in all the buckets and of course on the load factor. 


Note: depending on the hash function implementation, you may need to rehash the entire hash table because if the hash function depends on the capacity, then it may produce different results for existing keys when the capacity changes.  So, the simple System.arraycopy() might not suffice.  This is actually what is done in the JDK implementation.

2) Performance


Adding a new Entity to the linked list involves going through the entire list.  This seems inefficient.  Perhaps you can save the last node in a separate array that has same length as bucket? 
The usage of bucketItr seems redundant.  First of all, you copy bucket into bucketItr every time add() is called.  System.arraycopy() is efficient but that doesn't mean it need not be used judiciously. Moreover, the first line in iterator() initializes bucketItr from scratch, making the copy operation in add() completely redundant. but moreover, I don't see the reason for this array at all.  couldn't you loop on bucket in MapItr and just ignore null entries? 


3) Best Practices


References to generic type Entity&lt;K,T&gt; should be parameterized: Throughout the code, you refer to the Entity raw type, without the &lt;K, T&gt; generic parameters.  While it seems that this should not produce a bug, (since add() method only accept args of the correct types, this is still considered bad practice (and indeed produces compile warning).
The use of Objects.nonNull() is redundant.  why not use the simple and clear node != null? and while we are there, you first assign node to result and then ask about null. so theoretically, you could return null result.


4) Naming Conventions


an array of buckets should be named buckets or perhaps bucket_array don't you think?