Continuous Testing is an important part of a fast development process. You can detect bugs much faster and find them more easily since the code changes are smaller.
But that's independent from integrating my feature into the product of the main/master branch. I could also test very often on my feature branch and never integrate it. So it is a requirement for Continuous Integration but it's not restricted to only that integration model.
The difference between the two definitions of Continuous Integration is not that big. Both state, that you should integrate your features rapidly or multiple times a day.
If you cut your features into smaller parts, you can also merge them more often into your main/master branch. You should write your code in a non breaking way, to be able to integrate often. The continuous testing helps a lot to ensure, that the changes don't break anything.
The important part of CI is, that you get immediate feedback on your code and that each developer is working with the same code base. So you don't have bigger problems with merging of huge feature branches at the end of the development.
The problem with huge feature branches and late integration is the following: You finish your development and test everything on your feature branch. When you merge it into the main/master branch, the build breaks because there are some changes on main/master that are incompatible with yours. So you need to recode some parts, redo the tests and retry the merge.
This could be prevented, if everyone would be using the latest codebase and all changes are integrated into that codebase continuously.
You can also use trunk based development (https://trunkbaseddevelopment.com/) as an extreme form of CI. All work is done on the main/master branch, that is called trunk in this model. Extensive automated tests ensure, that your commits don't break anything.
There is no organisation that has the ownership of the concept Continuous Integration, so everyone could publish his or her own definition of it.
