When should be done Backlog Refinement Meeting?

Should I conduct Backlog Refinement meeting IN this sprint meeting?

Backlog refinement is not a part of the Sprint Planning meeting. It is however an ongoing activity and the Scrum Team can decide how they should be conducting this.

The below excerpt from the Scrum Guide should clarify things regarding this question.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team.

Scrum guide says development team can't remove items from sprint backlog ONLY PO can do this.

Scrum Guide does NOT say this. It says "When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint."

Don't confuse "deemed unnecessary" with deemed unable to be completed in time.

I thought we will have one refinement session per sprint and rest of status is done with daily scrum in tandem with looking into sprint backlog.

The purpose of the Daily Scrum is for the Dev team to prepare their plan for the day and not provide status for everything. They meet to ensure work is aligned by priority matching the Sprint Goal, identifying risks to completing the Sprint Goal and making progress that day, and together communicating what support they need before they get locked into their work for the day. It's to help them identify if they need support from anyone else on the team and to ensure no work performed is hidden from the Sprint Backlog.

Should I conduct Backlog Refinement meeting IN this sprint meeting?

Backlog Refinement is not a Scrum Event. It's optional use is to allow you and the team to help get the Backlog ready for Sprint Planning. Once the Backlog is healthy and you're prioritizing it daily, refinement would only ever happen as needed. To help you get there, anyone writing stories should know how to do so in such a way to have you as PO be able to effectively prioritize it. It's not to say each story needs to have all the details and be sized, but enough detail so that you can prioritize it by understanding the value of its completion. The rest of the details could come during Sprint Planning. Now, if the team isn't mature enough to be writing similar sized smaller stories, this effort could take considerable time. While that maturity is occuring, Backlog Refinement will also help get stories ready for Sprint Planning.

I am trying to push the item to the next sprint. Is my process correct?

If the bug is not deferrable, then the Story can't be called Done. There is no good reason to call the story done and push the bug to a future Sprint or Backlog unless it's deferrable and not directly caused by or preventing the ability for the value to be realized and functional.

Should I conduct Backlog Refinement meeting IN this sprint meeting?

What are your thoughts about the team reserving up to 10% of their time during each Sprint for Product Backlog refinement activities?

Also, Scrum guide says in the sprint backlog, add one item which aligns to process improvement from the previous retrospective. How do you guys do this? Any real example that you can give me is immensely useful.

Let’s turn this around a bit. Can you give us an example of a process improvement which your team has identified?

if backlog refinement is not to take up more than 10% capacity where do you represent this in your Sprint?

Do you just subtract it along with all the other Scrum Events ( Sprint Planning, Daily Standups, Retro and Review ) so that your team knows how much time they actually have to work on the tasks committed to? 

It's certainly important that the team knows their forecast is realistic for their commitments. If they reserve 10% of their time each Sprint for refinement, they may represent it on the Sprint Backlog if it helps them. They may choose not to represent it anywhere.

Per Scrum Guide, I do Sprint planning, my o/p is sprint goal and sprint backlog.

I don't know what you mean by o/p; however, the PO is responsible for the Product Goal and Product Backlog (PB), the Scrum team is responsible for the Sprint Goal, and the Developers are responsible for the Sprint Backlog. 

PB refinement can be performed at anytime, but should not take up more than 10% of the Developers time; whereas, the PO can spend as much time on it as needed. 

A previous version of the Scrum Guide did say that at least one improvement item should be added to the next sprints backlog; however, the current guide says that improvements may be added to the next sprints backlog. 

Concerning your PBI that now has a bug, if the Developers cannot resolve the bug by the end of the sprint, then the PBI is not Done; therefore it should be re-estimated and placed back into the PB.  During the next spring planning event, that PBI may or may not be selected by the developers based upon its relevance to that sprints goal.

The best PBI refinement comes when the developer is working with the business on the PBI they are working right now.

"After we achieve the goal of integrating mail into the list it will be easier to add items to the list. Which means we'll need a way of managing the list. Do you have ideas how that will go?"

Because the dev has a user right there helping produce work which has value.

Water that down too much, and you're back at waterfall.

10% of an 8 hour day is 3 x 15 minute meetings - or even better 9x 5 minute meetings. That's what continuous PBI refinement looks like.

Just going to point out that the current revision of the Scrum Guide does not have any suggested limit to how much time is used for refinement.  The word "refinement" is used exactly 1 time and it is in this paragraph from the section describing the Product Backlog.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

Continuous refinement is when the team constantly asks each other questions about things that need to be done to the Product. It isn't done in meetings. It doesn't even have to be done as a group.  Slack channels, comments in Jira tickets, email can all be used for refinement.  

Merriam-Webster defines "refinement" as 

the action or process of refining

"Refine" has this definition (one of many)

to free (something, such as metal, sugar, or oil) from impurities or unwanted material

So Product Backlog Item refinement would be the act of freeing from impurities or unwanted material.  Do that in any and every way possible on a ongoing basis. 

Constructive response @Daniel. People fail to understand that backlog refinement is not a specific ceremony, rather a continuous process adapted for how the team best operates. 

Product backlog refinement can be done for the current sprint as well since the items will be on sprint backlog at this time?

Ideally, if it is on the Sprint Backlog the item has already gone through refinement.  However, we all know that once you start working on something you will uncover new information.  So there will be some level of refinement that occurs as the work progresses.  But since that item is already in the Sprint Backlog, I would not consider that part of the refinement process.  That is now part of the development work. 

The Scrum Guide has one reference to the word "refinement". 

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. 

Notice it is in context of the Product Backlog not Sprint Backlog.  There is mention of the word "refine" in the section that describes Sprint Planning.

Topic Two: What can be Done this Sprint?

Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

As has been said previously, refinement is an ongoing activity that occurs and not a specific scheduled meeting or event.